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

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 3 Aug 2004 14:39:37 -0700

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.

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.

PatC

---

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

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

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: "Yang, Lily L" <[email-masked]>
Date: Tue, 3 Aug 2004 19:38:57 -0700

See comments below in line.

________________________________

Cc: [email-masked]; [email-masked]; [email-masked]

[Yang, Lily L] I also think that developing such a protocol for remote
MAC has challenges that are quite specific to this architecture, while
it is more feasible to develop a common protocol supporting both local
and split MAC.

[Yang, Lily L] I would also agree that the protocol should be
applicable, whether or not it is reachable via a wired network or some
wireless backbone (like 802.11 mesh). 

PatC