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

From: "Pat R. Calhoun" <[email-masked]>
Date: Tue, 3 Aug 2004 15:04:01 -0700

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: "Inderpreet Singh" <[email-masked]>
Date: Wed, 4 Aug 2004 00:39:37 -0400

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

---

From: Partha Narasimhan <[email-masked]>
Date: Wed, 04 Aug 2004 07:21:30 -0700

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

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Aug 2004 10:00:04 -0700

I agree.

            jak

----- Original Message ----- 
From: "Partha Narasimhan" <[email-masked]>
To: "Inderpreet Singh" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Wednesday, August 04, 2004 7:21 AM
Subject: RE: [Capwap] So many architectures, so little time... - take 2