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

From: "Yang, Lily L" <[email-masked]>
Date: Tue, 3 Aug 2004 19:43:45 -0700

Just one minor point about your comment  "the wireless backend is
mobile" - true, but the degree of mobility is likely to be very
different from the station mobility - TGs is still trying to define how
much  mobility it is required to support. In the case of home, office
and enterprise, mobility of the backend mesh is probably low; while
other usage scenarios may require higher degree of mobility.

________________________________

From: Mani, Mahalingam (Mahalingam) [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 7:37 PM
To: Pat R. Calhoun; James Kempf; Yang, Lily L;
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: So many architectures, so little time...

Just some minor points here...

________________________________

From: Pat R. Calhoun [mailto:[email-masked]] 
Sent: Tuesday, August 03, 2004 2:40 PM
To: James Kempf; Yang, Lily L; [email-masked];
[email-masked]
Cc: [email-masked]; Mani, Mahalingam (Mahalingam);
[email-masked]
Subject: So many architectures, so little time...

I'd like to discuss my take on the various architectures.

My belief is that standardizing the remote MAC architecture cannot be
an IETF problem. First, the timing requirements of the real-time
functions
of the MAC would create a significant challenge for the protocol
developers
as the reality is that interoperability between the infrastructure and
the
clients is paramount. Any architecture that now causes clients to no
longer
associate with the network is not terribly useful.

Then we have mesh networks. Mesh networks really consists of two
components:
1. Mesh Routing/Topology Discovery: I do not believe this is a problem
that is within our charter
2. The rest: I'm being a little vague here, but all of the normal AP
functions, such
as access control, is within the charter. A protocol designed by the WG
should be
applicable to any AP, regardless of whether it is reachable via a wired
network or
via some wireless medium.

[Mani, Mahalingam (Mahalingam)] the wireless backend is mobile. This
implies more involvement of addressing the details of meshnetworking

Into the protocol API rather than causing changes to the protocol itself
- if done right. That is always true - if the design is towards the more
general case of a mobile infrastructure - that should work for the
normal case (of wireline CAPWAP backhaul). A simpler way to approach is
also to ask ourselves what constitutes the WLAN control plane and its
scope while isolating considerations of the fastpath which could be a
union of multiple wireline and wireless (in case of mesh) hops.

[Mani, Mahalingam (Mahalingam)] it would be fair to say even a
meshnetwork of adhoc (mobile) BSSs will need a coordinating reference.
The AC abstraction addresses this - perhaps pending minor adjustments to
standardization of meshnetwork (802.11s).

As far as Local MAC, it's not clear that there is anything required
above and beyond
what already exists.

So I do believe that our goal should be to design a single protocol can
satisfy the
Split MAC approaches.

[Mani, Mahalingam (Mahalingam)] a reasonable argument - barring cases
where even autonomous APs leverage trivial control of a centralized AC.

[Mani, Mahalingam (Mahalingam)] -mani

PatC

---

From: "James Kempf" <[email-masked]>
Date: Tue, 3 Aug 2004 21:08:23 -0700

I think more to the point is that a wireless multihop backhaul probably will
require some changes at the MAC level, and 802.11s isn't there yet.

            jak

----- Original Message ----- 
From: "Yang, Lily L" <[email-masked]>
To: "Mani, Mahalingam (Mahalingam)" <[email-masked]>; "Pat R. Calhoun"
<[email-masked]>; "James Kempf" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 03, 2004 7:43 PM
Subject: RE: So many architectures, so little time...

PatC

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

---

From: Matt Holdrege <[email-masked]>
Date: Wed, 04 Aug 2004 13:03:24 +0200

Why? Changes from one MAC to another are completely covered in 802.

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Aug 2004 09:56:55 -0700

What I had in mind was the following. 802.11s is working on MAC changes for
multihop. I think it would be premature to do anything in IETF on multhop
until they had completed. And, as a practical matter, I've seen some
experimental data (unfortunately not public yet) that indicates changes are
needed at the MAC level. But I'm not sure exactly what your question was, so
maybe this didn't answer it.

            jak

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 05 Aug 2004 14:38:18 +0200

What I meant was that hops are easy in the sense of hopping from say 802.11 
to 802.3 then back to 802.11, then 802.3, etc. You can even do something 
like this on a chip. No new standardization is needed.

-Matt