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

From: "Abhijit Choudhury" <[email-masked]>
Date: Tue, 10 Aug 2004 23:17:43 -0700

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

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: "Saravanan Govindan" <[email-masked]>
Date: Wed, 11 Aug 2004 22:23:42 +0800

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

	for a standard.   And it's easier to implement in hardware or
software
	 
	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.

	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

	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 

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