Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data Tunneling

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 29 Sep 2005 15:00:39 -0700

In terms of option 2, no traffic is sent to the AC, so the model is
quite different.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Sadot, Emek (Emek) [mailto:[email-masked]] 
	Sent: Thursday, September 29, 2005 2:16 PM
	To: Pat Calhoun (pacalhou); [email-masked]
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local
MAC User Data Tunneling

	Pat, you certainly raise valid questions w.r.t. option #3,
however I am curious as to the differences between the challenges you
listed between options #2 and #3. In other words, in what sense option
#2 and #3 are differ w.r.t. encryption and 11e at the AC, as well as
RSSI/SNR/data-rate/other monitoring support?
	 
	Regards,
	Emek
	 
________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
	Sent: Wednesday, September 28, 2005 5:32 PM
	To: [email-masked]
	Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC
User Data Tunneling

	This change request is to allow for 802.3 tunneling of user data
in local bridging mode. I believe that the changes should be relatively
straightforward, but do introduce an interesting set of complications
that need to be evaluated and agreed upon as a group.
	 
	The LWAPP protocol currently allows for 802.11 tunneling in
Split-MAC mode, allowing for such things as centralized encryption of
user data frames. However, the current definition of the protocol is
that when running in Local-MAC mode, no traffic is tunneled to the
controller.
	 
	If we were to introduce this change, the LWAPP protocol would
have three modes of operation:
	1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11)
	2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames
	3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP
	 
	The issue that we need to decide as a group is whether we really
want a protocol that has three modes of operation, and if so, which one
is mandatory. The evaluation draft states that option 3 is useful for
support of non 802.11 technologies, but this introduces a set of
restrictions. For instance, today the LWAPP protocol allows for
centralized control of various 802.11 functions, including encryption
and 802.11e. This function is not possible with option 3, and therefore
any new technology that assumes this option would not be able to provide
centralization of data frame functions.
	 
	There is a comment in the recommendation that LWAPP could retain
the RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the
AC to have more visibility. However, I have had some requests to expand
these fields to also include the data rate. Further, there are possible
fields in the header (of technologies we know nothing about) that the
WTP may want to extract and expose to the AC - and how could this be
done with 802.3?

	Pat Calhoun
	CTO, Wireless Networking Business Unit
	Cisco Systems

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 30 Sep 2005 13:16:10 -0400

Regarding the points you raised I believe option #2 and #3 share the
same qualities.
In both options 802.11 encryption and 11e cannot be implemented at the
AC.
In both options a mechanism shall be design to extract RF and
data-traffic statistics either (a) appended in the tunneling (option #3
only) or (b) exposed by the WTP as read-only values for the AC inquiries
(both options).
 
Am I missing something?
 
On the other hand one can respect the unique merits that these options
offer:
- option 2: non-appliance product. meaning a software based AC that can
be executed on any server / platform.
- option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage
existing products (e.g. routers) with "only" add-on 802.11 code running
at the Cpu.
 
Emek

  _____  

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, September 29, 2005 6:01 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

Pat Calhoun

  _____  

	 
	Regards,
	Emek
	 
  _____  

	 

	 

	Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 1 Oct 2005 13:25:38 -0700

Emek,
 
In option 3, when a user associates with the WTP, the association is
handled locally, but the packet is tunneled to the AC in order for the
AC to have access to usage information (and make overriding policy
decisions). So 802.11 needs to be supported on the AC regardless, right?

Pat Calhoun

	From: Sadot, Emek (Emek) [mailto:[email-masked]] 
	Sent: Friday, September 30, 2005 10:16 AM
	To: Pat Calhoun (pacalhou); [email-masked]
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local
MAC User Data Tunneling

	Regarding the points you raised I believe option #2 and #3 share
the same qualities.
	In both options 802.11 encryption and 11e cannot be implemented
at the AC.
	In both options a mechanism shall be design to extract RF and
data-traffic statistics either (a) appended in the tunneling (option #3
only) or (b) exposed by the WTP as read-only values for the AC inquiries
(both options).
	 
	Am I missing something?
	 
	On the other hand one can respect the unique merits that these
options offer:
	- option 2: non-appliance product. meaning a software based AC
that can be executed on any server / platform.
	- option 3: avoid parse 802.11 traffic in silicon at the AC.
Leverage existing products (e.g. routers) with "only" add-on 802.11 code
running at the Cpu.
	 
	Emek

	In terms of option 2, no traffic is sent to the AC, so the model
is quite different.

	Pat Calhoun

		From: Sadot, Emek (Emek) [mailto:[email-masked]] 
		Sent: Thursday, September 29, 2005 2:16 PM
		To: Pat Calhoun (pacalhou); [email-masked]
		Subject: RE: [Capwap] Change Request 9.1.3.1. Support
for Local MAC User Data Tunneling

		Pat, you certainly raise valid questions w.r.t. option
#3, however I am curious as to the differences between the challenges
you listed between options #2 and #3. In other words, in what sense
option #2 and #3 are differ w.r.t. encryption and 11e at the AC, as well
as RSSI/SNR/data-rate/other monitoring support?
		 
		Regards,
		Emek

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
		Sent: Wednesday, September 28, 2005 5:32 PM
		To: [email-masked]
		Subject: [Capwap] Change Request 9.1.3.1. Support for
Local MAC User Data Tunneling

		This change request is to allow for 802.3 tunneling of
user data in local bridging mode. I believe that the changes should be
relatively straightforward, but do introduce an interesting set of
complications that need to be evaluated and agreed upon as a group.
		 
		The LWAPP protocol currently allows for 802.11 tunneling
in Split-MAC mode, allowing for such things as centralized encryption of
user data frames. However, the current definition of the protocol is
that when running in Local-MAC mode, no traffic is tunneled to the
controller.
		 
		If we were to introduce this change, the LWAPP protocol
would have three modes of operation:
		1. Split-MAC: Tunnel native MAC frames in UDP (e.g.,
802.11)
		2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames
		3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP
		 
		The issue that we need to decide as a group is whether
we really want a protocol that has three modes of operation, and if so,
which one is mandatory. The evaluation draft states that option 3 is
useful for support of non 802.11 technologies, but this introduces a set
of restrictions. For instance, today the LWAPP protocol allows for
centralized control of various 802.11 functions, including encryption
and 802.11e. This function is not possible with option 3, and therefore
any new technology that assumes this option would not be able to provide
centralization of data frame functions.
		 
		There is a comment in the recommendation that LWAPP
could retain the RSSI/SNR fields, and then perform 802.3 encapsulation,
allowing the AC to have more visibility. However, I have had some
requests to expand these fields to also include the data rate. Further,
there are possible fields in the header (of technologies we know nothing
about) that the WTP may want to extract and expose to the AC - and how
could this be done with 802.3?

		Pat Calhoun

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 29 Sep 2005 17:15:59 -0400

Pat, you certainly raise valid questions w.r.t. option #3, however I am
curious as to the differences between the challenges you listed between
options #2 and #3. In other words, in what sense option #2 and #3 are
differ w.r.t. encryption and 11e at the AC, as well as
RSSI/SNR/data-rate/other monitoring support?
 
Regards,
Emek
 
  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun (pacalhou)
Sent: Wednesday, September 28, 2005 5:32 PM
To: [email-masked]
Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

This change request is to allow for 802.3 tunneling of user data in
local bridging mode. I believe that the changes should be relatively
straightforward, but do introduce an interesting set of complications
that need to be evaluated and agreed upon as a group.
 
The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC
mode, allowing for such things as centralized encryption of user data
frames. However, the current definition of the protocol is that when
running in Local-MAC mode, no traffic is tunneled to the controller.
 
If we were to introduce this change, the LWAPP protocol would have three
modes of operation:
1. Split-MAC: Tunnel native MAC frames in UDP (e.g., 802.11)
2. Local-MAC w/ Local Bridge: Do not tunnel 802.3 frames
3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in UDP
 
The issue that we need to decide as a group is whether we really want a
protocol that has three modes of operation, and if so, which one is
mandatory. The evaluation draft states that option 3 is useful for
support of non 802.11 technologies, but this introduces a set of
restrictions. For instance, today the LWAPP protocol allows for
centralized control of various 802.11 functions, including encryption
and 802.11e. This function is not possible with option 3, and therefore
any new technology that assumes this option would not be able to provide
centralization of data frame functions.
 
There is a comment in the recommendation that LWAPP could retain the
RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC
to have more visibility. However, I have had some requests to expand
these fields to also include the data rate. Further, there are possible
fields in the header (of technologies we know nothing about) that the
WTP may want to extract and expose to the AC - and how could this be
done with 802.3?

Pat Calhoun

---

From: zhaoyujin 00919 <[email-masked]>
Date: Mon, 03 Oct 2005 09:57:35 +0500

Hi:

  Can we use the "add mobile frame" to notify AC create the usage information?

  Like above, CAPWAP can defined "local-local mac". All 802.11 frame is terminated on WTP. If there need communication between AC and AP, the LWAPP cotrol message can be used.

Best regards
Michael

> 	From: Sadot, Emek (Emek) [[email-masked]] 
> only) or (b) exposed by the WTP as read-only values for the AC 
> inquiries(both options).
>         
> 	Am I missing something?
>         
> 	From: Pat Calhoun (pacalhou) [[email-masked]] 
>        	From: Sadot, Emek (Emek) [[email-masked]] 
> [[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
> and 802.11e. This function is not possible with option 3, and 
> thereforeany new technology that assumes this option would not be 
> able to provide
> could retain the RSSI/SNR fields, and then perform 802.3 
> encapsulation,allowing the AC to have more visibility. However, I 
> have had some
> requests to expand these fields to also include the data rate. 
> Further,there are possible fields in the header (of technologies 
> we know nothing

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 5 Oct 2005 07:07:44 -0700

>   Like above, CAPWAP can defined "local-local mac". All 
> 802.11 frame is terminated on WTP. If there need 
> communication between AC and AP, the LWAPP cotrol message can be used.

Sure, that would be one approach, but it really seems unnecessary
complex as we already have a mechanism to exchange this information.
What you are proposing is for the WTP to translate the association
request to some new control protocol - seems like a lot of work with no
specific gain.

Pat Calhoun

> -----Original Message-----
> From: zhaoyujin 00919 [mailto:[email-masked]] 
> Sent: Sunday, October 02, 2005 9:58 PM
> To: Pat Calhoun (pacalhou)
> Cc: [email-masked]
> Subject: RE: [Capwap] Change Request 9.1.3.1. Support for 
> > CTO, Wireless Networking Business Unit Cisco Systems
> > 
> > 
> > 
> > 
> > 	In both options 802.11 encryption and 11e cannot be 
> implemented at 
> > the AC.
> > data-traffic statistics either (a) appended in the 
> tunneling (option 
> > #3
> > 	- option 2: non-appliance product. meaning a software 
> based AC that 
> > can be executed on any server / platform.
> >        	Subject: RE: [Capwap] Change Request 9.1.3.1. 
> Support for 
> >        	Subject: [Capwap] Change Request 9.1.3.1. 
> Support for Local 
> > MAC User Data Tunneling
> >        	
> >        	
> >        	This change request is to allow for 802.3 
> tunneling of user 
> > data in local bridging mode. I believe that the changes should be 
> >        	The issue that we need to decide as a group is 
> whether we 
> > really want a protocol that has three modes of operation, 
> and if so, 
> > useful for support of non 802.11 technologies, but this 
> introduces a 
> > set of restrictions. For instance, today the LWAPP protocol 
> allows for 
> > thereforeany new technology that assumes this option would 
> not be able 
> > to provide centralization of data frame functions.
> >                 
> >        	There is a comment in the recommendation that 
> LWAPP could 
> > retain the RSSI/SNR fields, and then perform 802.3 
> > encapsulation,allowing the AC to have more visibility. 
> However, I have 
> > had some requests to expand these fields to also include the data 
> > rate.
> > Further,there are possible fields in the header (of technologies we 
> > know nothing

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 6 Oct 2005 13:17:52 -0400

Pat,
 
Yes, that's how I interpreted it, with a disclaimer for 802.11 control
and management frames only.
It goes for option #3 and #2.
 
Regards,
Emek

  _____  

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Saturday, October 01, 2005 4:26 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

Emek,

Pat Calhoun

  _____  

	 
	Am I missing something?

	Emek

  _____  

	Pat Calhoun

  _____  

		 
		Regards,
		Emek
		 
  _____  

		 

		 

		Pat Calhoun

---

From: "Darren Loher" <[email-masked]>
Date: Fri, 14 Oct 2005 10:31:16 -0700

The evaluation draft made a strongly recommendation that an option for a
Local-MAC mode with user data tunneling be explored on by the working
group.  The eval draft listed a few reasons why it might be worth having
such a solution.  I heard support for such a solution from members of
the working group off and on the mailing list.   In addition, it appears
to be an innovative solution which CTP and SLAPP allowed for in some
way.

There are many details that need to be specified for exactly how this
would work which we are starting to talk about.  However, it is useful
to hear from the WG at large if a capability like this is necessary.  

Is a capability for tunneling of user data in 802.3 format for Local MAC
mode needed?  

-Darren

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sadot, Emek (Emek)
Sent: Thursday, October 06, 2005 11:18 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

Pat,

Regards,

Emek

Emek,

Pat Calhoun

	Am I missing something?

	Emek

	Pat Calhoun

		Regards,

		Emek

		Pat Calhoun

---

From: Michael Montemurro <[email-masked]>
Date: Fri, 14 Oct 2005 14:27:43 -0400

From my point of view, supporting Local MAC in both a tunnel mode (user data
tunnelling between the AC and the WTP) and local mode ( bridging locally at
the WTP) allows the protocol to be applied to a wide variety of network
deployments. It must be supported by the protocol.
 
As for the frame format, from my point of view, in a split MAC case, it
would much easier to use 802.11 frames for data frame tunnelling, but for
the local MAC case, it is much easier to use 802.3 frames. 
 
A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks as
follows:
 
802.11:  Frame CTL    Duration    DA    SA    RA/BSSID    Sequence Control
Address4 (WDS)    QoS Control    Frame Body    FCS
802.3:                                        DA    SA    Priority    CFI
VLAN                                                                   Frame
Body    FCS
 
Comments on comparison of the two formats:
- Frame CTL, Sequence Control, and Duration are of limited value at the AC
for local MAC, they may be useful depending on how you define split MAC
- FCS for 802.11 and FCS for 802.3 are calculated differently, I believe
- There is a well defined mapping between QoS Control in 802.11 and Priority
802.1p bits in 802.3
- There is an implicit mapping between BSSID and VLAN tag
- One open issue would be how to address 802.11e Admission Control
 
802.3 provides the basic imformation that the WTP or the AC needs to process
packets in the local MAC case. It would probably provide enough information
depending on how you define split MAC. However, you may be able to move some
of that information into the CAPWAP header if you used an 802.3 frame
format.
 
One of the issues we have is that if you read the Taxonomy document, the
definition of local MAC and to some extent, even split MAC, are open to
interpretation. That is why Pat, Inderpreet, and Bob submitted the Taxonomy
Recommendations document at the last meeting.
 
Cheers,
 
    Mike

  _____  

From: Darren Loher [mailto:[email-masked]] 
Sent: October 14, 2005 1:31 PM
To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); [email-masked]; Puneet
Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

The evaluation draft made a strongly recommendation that an option for a
Local-MAC mode with user data tunneling be explored on by the working group.
The eval draft listed a few reasons why it might be worth having such a
solution.  I heard support for such a solution from members of the working
group off and on the mailing list.   In addition, it appears to be an
innovative solution which CTP and SLAPP allowed for in some way.

There are many details that need to be specified for exactly how this would
work which we are starting to talk about.  However, it is useful to hear
from the WG at large if a capability like this is necessary.  

-Darren

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadot, Emek (Emek)
Sent: Thursday, October 06, 2005 11:18 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

Pat,

Yes, that's how I interpreted it, with a disclaimer for 802.11 control and
management frames only.

Regards,

Emek

  _____  

Emek,

In option 3, when a user associates with the WTP, the association is handled
locally, but the packet is tunneled to the AC in order for the AC to have
access to usage information (and make overriding policy decisions). So
802.11 needs to be supported on the AC regardless, right?

Pat Calhoun

  _____  

Regarding the points you raised I believe option #2 and #3 share the same
qualities.

In both options 802.11 encryption and 11e cannot be implemented at the AC.

In both options a mechanism shall be design to extract RF and data-traffic
statistics either (a) appended in the tunneling (option #3 only) or (b)
exposed by the WTP as read-only values for the AC inquiries (both options).

Am I missing something?

- option 2: non-appliance product. meaning a software based AC that can be
executed on any server / platform.

- option 3: avoid parse 802.11 traffic in silicon at the AC. Leverage
existing products (e.g. routers) with "only" add-on 802.11 code running at
the Cpu.

Emek

  _____  

In terms of option 2, no traffic is sent to the AC, so the model is quite
different.

Pat Calhoun

  _____  

Pat, you certainly raise valid questions w.r.t. option #3, however I am
curious as to the differences between the challenges you listed between
options #2 and #3. In other words, in what sense option #2 and #3 are differ
w.r.t. encryption and 11e at the AC, as well as RSSI/SNR/data-rate/other
monitoring support?

Regards,

Emek

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun (pacalhou)
Sent: Wednesday, September 28, 2005 5:32 PM
To: [email-masked]
Subject: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data
Tunneling

This change request is to allow for 802.3 tunneling of user data in local
bridging mode. I believe that the changes should be relatively
straightforward, but do introduce an interesting set of complications that
need to be evaluated and agreed upon as a group.

The LWAPP protocol currently allows for 802.11 tunneling in Split-MAC mode,
allowing for such things as centralized encryption of user data frames.
However, the current definition of the protocol is that when running in
Local-MAC mode, no traffic is tunneled to the controller.

The issue that we need to decide as a group is whether we really want a
protocol that has three modes of operation, and if so, which one is
mandatory. The evaluation draft states that option 3 is useful for support
of non 802.11 technologies, but this introduces a set of restrictions. For
instance, today the LWAPP protocol allows for centralized control of various
802.11 functions, including encryption and 802.11e. This function is not
possible with option 3, and therefore any new technology that assumes this
option would not be able to provide centralization of data frame functions.

There is a comment in the recommendation that LWAPP could retain the
RSSI/SNR fields, and then perform 802.3 encapsulation, allowing the AC to
have more visibility. However, I have had some requests to expand these
fields to also include the data rate. Further, there are possible fields in
the header (of technologies we know nothing about) that the WTP may want to
extract and expose to the AC - and how could this be done with 802.3?

Pat Calhoun

---

From: "Puneet Agarwal" <[email-masked]>
Date: Fri, 14 Oct 2005 17:15:39 -0700

I concur with Darren and Mike. Supporting Local MAC in both tunnel and local
mode allows for a rich set of network deployments and hence must be supported
by CAPWAP.
 
Thanks.
 
-Puneet
[resending as the previous html reply was being flagged as too big by the
reflector]

From: Michael Montemurro [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 11:28 AM
To: Darren Loher; Sadot, Emek (Emek); Pat Calhoun (pacalhou);
[email-masked]; Puneet Agarwal; Saravanan Govindan; Dan Harkins
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User Data
Tunneling

As for the frame format, from my point of view, in a split MAC case, it would
much easier to use 802.11 frames for data frame tunnelling, but for the local
MAC case, it is much easier to use 802.3 frames. 

 
 
802.3 provides the basic imformation that the WTP or the AC needs to process
packets in the local MAC case. It would probably provide enough information
depending on how you define split MAC. However, you may be able to move some
of that information into the CAPWAP header if you used an 802.3 frame format.

Cheers,
 
    Mike

	From: Darren Loher [mailto:[email-masked]] 
	Sent: October 14, 2005 1:31 PM
	To: Sadot, Emek (Emek); Pat Calhoun (pacalhou); [email-masked];
Puneet Agarwal; Michael Montemurro; Saravanan Govindan; Dan Harkins
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC
User Data Tunneling

	The evaluation draft made a strongly recommendation that an option
for a Local-MAC mode with user data tunneling be explored on by the working
group.  The eval draft listed a few reasons why it might be worth having such
a solution.  I heard support for such a solution from members of the working
group off and on the mailing list.   In addition, it appears to be an
innovative solution which CTP and SLAPP allowed for in some way.

	There are many details that need to be specified for exactly how this
would work which we are starting to talk about.  However, it is useful to
hear from the WG at large if a capability like this is necessary.  

	Is a capability for tunneling of user data in 802.3 format for Local
MAC mode needed?  

	-Darren

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
	Sent: Thursday, October 06, 2005 11:18 AM
	To: Pat Calhoun (pacalhou); [email-masked]
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC
User Data Tunneling

	Pat,

	Yes, that's how I interpreted it, with a disclaimer for 802.11
control and management frames only.

	Regards,

	Emek

		From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
	Sent: Saturday, October 01, 2005 4:26 PM
	To: Sadot, Emek (Emek); [email-masked]
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC
User Data Tunneling

	Emek,

	In option 3, when a user associates with the WTP, the association is
handled locally, but the packet is tunneled to the AC in order for the AC to
have access to usage information (and make overriding policy decisions). So
802.11 needs to be supported on the AC regardless, right?

	Pat Calhoun

				From: Sadot, Emek (Emek)
[mailto:[email-masked]] 

		Regarding the points you raised I believe option #2 and #3
share the same qualities.

implemented at the AC.

		In both options a mechanism shall be design to extract RF and
data-traffic statistics either (a) appended in the tunneling (option #3 only)
or (b) exposed by the WTP as read-only values for the AC inquiries (both
options).

		Am I missing something?

		On the other hand one can respect the unique merits that
these options offer:

		- option 2: non-appliance product. meaning a software based
AC that can be executed on any server / platform.

		Emek

				From: Pat Calhoun (pacalhou)
[mailto:[email-masked]] 
		Sent: Thursday, September 29, 2005 6:01 PM
		To: Sadot, Emek (Emek); [email-masked]
		Subject: RE: [Capwap] Change Request 9.1.3.1. Support for
Local MAC User Data Tunneling

		In terms of option 2, no traffic is sent to the AC, so the
model is quite different.

		Pat Calhoun

						From: Sadot, Emek (Emek)
[mailto:[email-masked]] 

			Pat, you certainly raise valid questions w.r.t.
option #3, however I am curious as to the differences between the challenges
you listed between options #2 and #3. In other words, in what sense option #2
and #3 are differ w.r.t. encryption and 11e at the AC, as well as
RSSI/SNR/data-rate/other monitoring support?

			Regards,

			Emek

						From:
[email-masked] [mailto:[email-masked]] On Behalf Of Pat
Calhoun (pacalhou)
			Sent: Wednesday, September 28, 2005 5:32 PM
			To: [email-masked]
			Subject: [Capwap] Change Request 9.1.3.1. Support for
Local MAC User Data Tunneling

			This change request is to allow for 802.3 tunneling
of user data in local bridging mode. I believe that the changes should be
relatively straightforward, but do introduce an interesting set of
complications that need to be evaluated and agreed upon as a group.

			The LWAPP protocol currently allows for 802.11
tunneling in Split-MAC mode, allowing for such things as centralized
encryption of user data frames. However, the current definition of the
protocol is that when running in Local-MAC mode, no traffic is tunneled to
the controller.

			If we were to introduce this change, the LWAPP
protocol would have three modes of operation:

			2. Local-MAC w/ Local Bridge: Do not tunnel 802.3
frames

			The issue that we need to decide as a group is
whether we really want a protocol that has three modes of operation, and if
so, which one is mandatory. The evaluation draft states that option 3 is
useful for support of non 802.11 technologies, but this introduces a set of
restrictions. For instance, today the LWAPP protocol allows for centralized
control of various 802.11 functions, including encryption and 802.11e. This
function is not possible with option 3, and therefore any new technology that
assumes this option would not be able to provide centralization of data frame
functions.

			There is a comment in the recommendation that LWAPP
could retain the RSSI/SNR fields, and then perform 802.3 encapsulation,
allowing the AC to have more visibility. However, I have had some requests to
expand these fields to also include the data rate. Further, there are
possible fields in the header (of technologies we know nothing about) that
the WTP may want to extract and expose to the AC - and how could this be done
with 802.3?

			Pat Calhoun

---

From: "Saravanan Govindan" <[email-masked]>
Date: Mon, 17 Oct 2005 12:16:22 +0800

Dareen,

I agree with the recommendation for user data tunneling. From a
practical point, the Architecture Taxonomy points out that there are
designs in which user data is tunneled to the AC for local-MAC WTPs. So
it is important for the CAPWAP protocol address these types of WLAN
products.

Saravanan

	From: Darren Loher [mailto:[email-masked]] 
	Sent: Saturday, October 15, 2005 1:31 AM
	To: Sadot, Emek (Emek); Pat Calhoun (pacalhou);
[email-masked]; Puneet Agarwal; Michael Montemurro; Saravanan
Govindan; Dan Harkins
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local
MAC User Data Tunneling

	The evaluation draft made a strongly recommendation that an
option for a Local-MAC mode with user data tunneling be explored on by
the working group.  The eval draft listed a few reasons why it might be
worth having such a solution.  I heard support for such a solution from
members of the working group off and on the mailing list.   In addition,
it appears to be an innovative solution which CTP and SLAPP allowed for
in some way.

	There are many details that need to be specified for exactly how
this would work which we are starting to talk about.  However, it is
useful to hear from the WG at large if a capability like this is
necessary.  

	Is a capability for tunneling of user data in 802.3 format for
Local MAC mode needed?  

	-Darren

	Pat,

	Regards,

	Emek

	Emek,

	In option 3, when a user associates with the WTP, the
association is handled locally, but the packet is tunneled to the AC in
order for the AC to have access to usage information (and make
overriding policy decisions). So 802.11 needs to be supported on the AC
regardless, right?

	Pat Calhoun

				From: Sadot, Emek (Emek)

		Regarding the points you raised I believe option #2 and
#3 share the same qualities.

		In both options a mechanism shall be design to extract
RF and data-traffic statistics either (a) appended in the tunneling
(option #3 only) or (b) exposed by the WTP as read-only values for the
AC inquiries (both options).

		Am I missing something?

		- option 2: non-appliance product. meaning a software
based AC that can be executed on any server / platform.

		- option 3: avoid parse 802.11 traffic in silicon at the
AC. Leverage existing products (e.g. routers) with "only" add-on 802.11
code running at the Cpu.

		Emek

		In terms of option 2, no traffic is sent to the AC, so
the model is quite different.

		Pat Calhoun

						From: Sadot, Emek (Emek)
Support for Local MAC User Data Tunneling

			Pat, you certainly raise valid questions w.r.t.
option #3, however I am curious as to the differences between the
challenges you listed between options #2 and #3. In other words, in what
sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC,
as well as RSSI/SNR/data-rate/other monitoring support?

			Regards,

			Emek

						From:
[email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun (pacalhou)
			Sent: Wednesday, September 28, 2005 5:32 PM
			To: [email-masked]
			Subject: [Capwap] Change Request 9.1.3.1.
Support for Local MAC User Data Tunneling

			This change request is to allow for 802.3
tunneling of user data in local bridging mode. I believe that the
changes should be relatively straightforward, but do introduce an
interesting set of complications that need to be evaluated and agreed
upon as a group.

			The LWAPP protocol currently allows for 802.11
tunneling in Split-MAC mode, allowing for such things as centralized
encryption of user data frames. However, the current definition of the
protocol is that when running in Local-MAC mode, no traffic is tunneled
to the controller.

			1. Split-MAC: Tunnel native MAC frames in UDP
(e.g., 802.11)

			2. Local-MAC w/ Local Bridge: Do not tunnel
802.3 frames

			3. Local-MAC w/ Tunnel: Tunnel 802.3 frames in
UDP

			The issue that we need to decide as a group is
whether we really want a protocol that has three modes of operation, and
if so, which one is mandatory. The evaluation draft states that option 3
is useful for support of non 802.11 technologies, but this introduces a
set of restrictions. For instance, today the LWAPP protocol allows for
centralized control of various 802.11 functions, including encryption
and 802.11e. This function is not possible with option 3, and therefore
any new technology that assumes this option would not be able to provide
centralization of data frame functions.

			There is a comment in the recommendation that
LWAPP could retain the RSSI/SNR fields, and then perform 802.3
encapsulation, allowing the AC to have more visibility. However, I have
had some requests to expand these fields to also include the data rate.
Further, there are possible fields in the header (of technologies we
know nothing about) that the WTP may want to extract and expose to the
AC - and how could this be done with 802.3?

			Pat Calhoun

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 18 Oct 2005 11:10:53 -0400

Reaffirming my statement below: I'm supportive in supporting tunneling
and local mode from Local-MAC architecture. I would encourage the group
to consider the latter as the default mode, as such mode could encompass
most of the deployments today.
 
Regards,
Emek

(resending as plain text format as the previous html was, presumably,
too big)

From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Friday, October 14, 2005 5:18 PM
To: Michael Montemurro; Darren Loher; Sadot, Emek (Emek); Pat Calhoun
(pacalhou); [email-masked]; Saravanan Govindan; Dan Harkins
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

I concur with Darren and Mike. Supporting Local MAC in both tunnel and
local mode allows for a rich set of network deployments and hence must
be supported by CAPWAP.
 
Thanks.
 
-Puneet

From my point of view, supporting Local MAC in both a tunnel mode (user
data tunnelling between the AC and the WTP) and local mode ( bridging
locally at the WTP) allows the protocol to be applied to a wide variety
of network deployments. It must be supported by the protocol.
 
As for the frame format, from my point of view, in a split MAC case, it
would much easier to use 802.11 frames for data frame tunnelling, but
for the local MAC case, it is much easier to use 802.3 frames. 
 
A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY) looks
as follows:
 
802.11:  Frame CTL    Duration    DA    SA    RA/BSSID    Sequence
Control    Address4 (WDS)    QoS Control    Frame Body    FCS
802.3:                                        DA    SA    Priority
CFI    VLAN
Frame Body    FCS
 
Comments on comparison of the two formats:
- Frame CTL, Sequence Control, and Duration are of limited value at the
AC for local MAC, they may be useful depending on how you define split
MAC
- FCS for 802.11 and FCS for 802.3 are calculated differently, I believe
- There is a well defined mapping between QoS Control in 802.11 and
Priority 802.1p bits in 802.3
- There is an implicit mapping between BSSID and VLAN tag
- One open issue would be how to address 802.11e Admission Control
 
802.3 provides the basic imformation that the WTP or the AC needs to
process packets in the local MAC case. It would probably provide enough
information depending on how you define split MAC. However, you may be
able to move some of that information into the CAPWAP header if you used
an 802.3 frame format.
 
One of the issues we have is that if you read the Taxonomy document, the
definition of local MAC and to some extent, even split MAC, are open to
interpretation. That is why Pat, Inderpreet, and Bob submitted the
Taxonomy Recommendations document at the last meeting.
 
Cheers,
 
    Mike

	-Darren

	Pat,

	Regards,

	Emek

	Emek,

	Pat Calhoun

				From: Sadot, Emek (Emek)

		Am I missing something?

		Emek

		Pat Calhoun

						From: Sadot, Emek (Emek)

			Regards,

			Emek

						From:

			Pat Calhoun

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Wed, 19 Oct 2005 12:32:34 -0400

Pat,
 
I share your concern about complexity increasing, and I concur that we
should shy away as much as possible, but isn't the Local-MAC with
tunneling architecture is simply an hybrid of Split-MAC and Local-MAC
with DS at the WTP, excluding an indication as of which layer 2 the
tunneling carries - 802.11 or 802.3?

In other words, and please correct me if I am wrong, Local-MAC with
tunneling mode just make use, and re-position, Local-MAC with DS at the
WTP and Split MAC internal components.
Examples would be: reuse of Split-MAC DS support at the AC, or reuse the
802.11 to 802.3 converting function at the Local-MAC WTP, or reuse
Local-MAC method to convey 802.11 MAC info (e.g. RSSI) to the AC, etc.

Regards,
Emek

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2005 11:53 AM
To: Sadot, Emek (Emek); Puneet Agarwal; Michael Montemurro; Darren
Loher; [email-masked]; Saravanan Govindan; Dan Harkins
Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local MAC User
Data Tunneling

My personal opinion is that we should not, and for one reason only -
decreased complexity. What I am concerned about is the raw number of
tunneling options and modes of operation the protocol will end up having
to support. That said, I will go with the group's sentiment (which so
far is in agreement with this suggestion). Regardless of whether this
work is included or not, I agree with Emek's recommendation for the
default mode (which I believe is a point made in the Taxonomy
recommmendations draft).

Pat Calhoun

	From: Sadot, Emek (Emek) [mailto:[email-masked]] 
	Sent: Monday, October 17, 2005 8:39 AM
	To: Puneet Agarwal; Michael Montemurro; Darren Loher; Pat
Calhoun (pacalhou); [email-masked]; Saravanan Govindan; Dan Harkins
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local
MAC User Data Tunneling

	Reaffirming my statement below: I'm supportive in supporting
tunneling and local mode from Local-MAC architecture. I would even
suggest that the group would consider the latter as the default mode, as
such mode could encompass most of the deployments today.
	 
	Regards,
	Emek

	From: Puneet Agarwal [mailto:[email-masked]] 
	Sent: Friday, October 14, 2005 5:18 PM
	To: Michael Montemurro; Darren Loher; Sadot, Emek (Emek); Pat
Calhoun (pacalhou); [email-masked]; Saravanan Govindan; Dan Harkins
	Subject: RE: [Capwap] Change Request 9.1.3.1. Support for Local
MAC User Data Tunneling

	I concur with Darren and Mike. Supporting Local MAC in both
tunnel and local mode allows for a rich set of network deployments and
hence must be supported by CAPWAP.
	 
	Thanks.
	 
	-Puneet

	From my point of view, supporting Local MAC in both a tunnel
mode (user data tunnelling between the AC and the WTP) and local mode (
bridging locally at the WTP) allows the protocol to be applied to a wide
variety of network deployments. It must be supported by the protocol.
	 
	As for the frame format, from my point of view, in a split MAC
case, it would much easier to use 802.11 frames for data frame
tunnelling, but for the local MAC case, it is much easier to use 802.3
frames. 
	 
	A comparison of an 802.11 frame to an 802.3 frame (ignoring PHY)
looks as follows:
	 
	802.11:  Frame CTL    Duration    DA    SA    RA/BSSID
Sequence Control    Address4 (WDS)    QoS Control    Frame Body    FCS
	802.3:                                        DA    SA
Priority    CFI    VLAN
Frame Body    FCS
	 
	Comments on comparison of the two formats:
	- Frame CTL, Sequence Control, and Duration are of limited value
at the AC for local MAC, they may be useful depending on how you define
split MAC
	- FCS for 802.11 and FCS for 802.3 are calculated differently, I
believe
	- There is a well defined mapping between QoS Control in 802.11
and Priority 802.1p bits in 802.3
	- There is an implicit mapping between BSSID and VLAN tag
	- One open issue would be how to address 802.11e Admission
Control
	 
	802.3 provides the basic imformation that the WTP or the AC
needs to process packets in the local MAC case. It would probably
provide enough information depending on how you define split MAC.
However, you may be able to move some of that information into the
CAPWAP header if you used an 802.3 frame format.
	 
	One of the issues we have is that if you read the Taxonomy
document, the definition of local MAC and to some extent, even split
MAC, are open to interpretation. That is why Pat, Inderpreet, and Bob
submitted the Taxonomy Recommendations document at the last meeting.
	 
	Cheers,
	 
	    Mike

		The evaluation draft made a strongly recommendation that
an option for a Local-MAC mode with user data tunneling be explored on
by the working group.  The eval draft listed a few reasons why it might
be worth having such a solution.  I heard support for such a solution
from members of the working group off and on the mailing list.   In
addition, it appears to be an innovative solution which CTP and SLAPP
allowed for in some way.

		There are many details that need to be specified for
exactly how this would work which we are starting to talk about.
However, it is useful to hear from the WG at large if a capability like
this is necessary.  

		Is a capability for tunneling of user data in 802.3
format for Local MAC mode needed?  

		-Darren

		Pat,

		Yes, that's how I interpreted it, with a disclaimer for
802.11 control and management frames only.

		Regards,

		Emek

		Emek,

		Pat Calhoun

						From: Sadot, Emek (Emek)

			Regarding the points you raised I believe option
#2 and #3 share the same qualities.

			In both options 802.11 encryption and 11e cannot
be implemented at the AC.

			In both options a mechanism shall be design to
extract RF and data-traffic statistics either (a) appended in the
tunneling (option #3 only) or (b) exposed by the WTP as read-only values
for the AC inquiries (both options).

			Am I missing something?

			On the other hand one can respect the unique
merits that these options offer:

			- option 2: non-appliance product. meaning a
software based AC that can be executed on any server / platform.

			- option 3: avoid parse 802.11 traffic in
silicon at the AC. Leverage existing products (e.g. routers) with "only"
add-on 802.11 code running at the Cpu.

			Emek

						From: Pat Calhoun
(pacalhou) [mailto:[email-masked]] 

			In terms of option 2, no traffic is sent to the
AC, so the model is quite different.

			Pat Calhoun

								From:
Sadot, Emek (Emek) [mailto:[email-masked]] 
				Sent: Thursday, September 29, 2005 2:16
PM
				To: Pat Calhoun (pacalhou);
[email-masked]
				Subject: RE: [Capwap] Change Request
9.1.3.1. Support for Local MAC User Data Tunneling

				Pat, you certainly raise valid questions
w.r.t. option #3, however I am curious as to the differences between the
challenges you listed between options #2 and #3. In other words, in what
sense option #2 and #3 are differ w.r.t. encryption and 11e at the AC,
as well as RSSI/SNR/data-rate/other monitoring support?

				Regards,

				Emek

								From:
[email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun (pacalhou)
				Sent: Wednesday, September 28, 2005 5:32
PM
				To: [email-masked]
				Subject: [Capwap] Change Request
9.1.3.1. Support for Local MAC User Data Tunneling

				This change request is to allow for
802.3 tunneling of user data in local bridging mode. I believe that the
changes should be relatively straightforward, but do introduce an
interesting set of complications that need to be evaluated and agreed
upon as a group.

				The LWAPP protocol currently allows for
802.11 tunneling in Split-MAC mode, allowing for such things as
centralized encryption of user data frames. However, the current
definition of the protocol is that when running in Local-MAC mode, no
traffic is tunneled to the controller.

				If we were to introduce this change, the
LWAPP protocol would have three modes of operation:

				1. Split-MAC: Tunnel native MAC frames
in UDP (e.g., 802.11)

				2. Local-MAC w/ Local Bridge: Do not
tunnel 802.3 frames

				3. Local-MAC w/ Tunnel: Tunnel 802.3
frames in UDP

				The issue that we need to decide as a
group is whether we really want a protocol that has three modes of
operation, and if so, which one is mandatory. The evaluation draft
states that option 3 is useful for support of non 802.11 technologies,
but this introduces a set of restrictions. For instance, today the LWAPP
protocol allows for centralized control of various 802.11 functions,
including encryption and 802.11e. This function is not possible with
option 3, and therefore any new technology that assumes this option
would not be able to provide centralization of data frame functions.

				There is a comment in the recommendation
that LWAPP could retain the RSSI/SNR fields, and then perform 802.3
encapsulation, allowing the AC to have more visibility. However, I have
had some requests to expand these fields to also include the data rate.
Further, there are possible fields in the header (of technologies we
know nothing about) that the WTP may want to extract and expose to the
AC - and how could this be done with 802.3?

				Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 20 Oct 2005 04:40:23 -0700

Yes, you are correct in your understanding, but I still contend it is
one more mode to support.

Pat Calhoun

> Sent: Wednesday, October 19, 2005 9:33 AM
> To: Pat Calhoun (pacalhou); Puneet Agarwal; Michael 
> Montemurro; Darren Loher; [email-masked]; Saravanan 
> Govindan; Dan Harkins
> I share your concern about complexity increasing, and I 
> concur that we should shy away as much as possible, but isn't 
> the Local-MAC with tunneling architecture is simply an hybrid 
> of Split-MAC and Local-MAC with DS at the WTP, excluding an 
> indication as of which layer 2 the tunneling carries - 802.11 
> or 802.3?
> 
> In other words, and please correct me if I am wrong, 
> Local-MAC with tunneling mode just make use, and re-position, 
> Local-MAC with DS at the WTP and Split MAC internal components.
> 802.11 to 802.3 converting function at the Local-MAC WTP, or 
> reuse Local-MAC method to convey 802.11 MAC info (e.g. RSSI) 
> to the AC, etc.
> 
> Regards,
> Emek
> 
> To: Sadot, Emek (Emek); Puneet Agarwal; Michael Montemurro; 
> Darren Loher; [email-masked]; Saravanan Govindan; Dan Harkins