Subject: RE: [Capwap] Support for Traffic Separation

From: "Darren Loher" <[email-masked]>
Date: Thu, 16 Jun 2005 16:44:31 -0700

Given the following scenarios:

 1) Split MAC - Bridge at WTP  

 2) Split MAC - Bridge at AC

 3) Local MAC - Bridge at WTP

 4) Local MAC - Bridge at AC

I agree that #2-4 are required scenarios.  I am not sure that #1 is
required.  If "bridge" means the IS function, #1 would be in conflict
with the recent error correction/update of the taxonomy document.

When the IS function is implemented at the WTP, the WTP must be a local
MAC WTP.  However, in a local MAC scenario the CAPWAP protocol must
still permit tunneling or not tunneling user traffic to an AC.  A
particular WTP device may not support this function, but the CAPWAP
protocol MUST allow it (IMHO).  This would be compatible with the new
update/error correction to the taxonomy document and gives flexibility
for implementers to create traffic separation if they choose in split
and local MAC modes.

What does everyone think? (did I miss anything?)

-Darren

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Inderpreet Singh
Sent: Thursday, June 16, 2005 4:02 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

>>"Further, one must assume that there are functions that reside in the
AC that are much more than 

>>just "tunnel termination", and if this is the case these functions are
lost when you resort to bridge 

>>mode." - I assume you meant that some functionality will be lost if
bridging is implemented at the WTP, 

>>so if that's your argument then the counter argument would be: how
these functions being materialized 

>>in Local MAc arch?

If I am not mistaken, this discussion has let to two interpretations of
the word "bridging" as well.

1.	Emek understands bridging as 802.11 to 802.3 conversion.  Which
is technically correct, but really confined definition in our context.
I think it would be useful to term in 802.11 MAC termination rather than
simply bridging.
2.	Pat, Mike and I believe that bridging in this context has to do
with bridging the user traffic to the local physical interface.  Usually
this is Ethernet in the WTP case.  Non-bridging would be where the
traffic is tunneled to the AC.

So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated
Locally and then the resulting 802.3 packets are bridged to the local
physical interface), then it is possible for example to lose the
functionality of L3 roaming of the client.  However, in certain
scenarios of deployments where this function/feature is not needed,
local bridging is quite useful.

Thanks

Inderpreet

________________________________

From: Pat Calhoun [mailto:[email-masked]] 
Sent: Thursday, June 16, 2005 5:25 PM
To: Sadot, Emek (Emek); 'Michael Montemurro'; [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

> Giving the operator / customer the freedom to run the IS function in
AC or WTP is important and as far as I can tell doesn't 

> break the CAPWAP model. Why it's important: well take #1 for example,
if customer wishes to session to travel along 

> the shorter path between peers, or maintain existing voice call when
AC experience a failover and perform reboot (but new 

> session or roaming obviously)."

Emek, I don't see how this can be achieved. A user's end device has a
single IP address. One really cannot split the forwarding of user
traffic based on the relative priority of the traffic or based on
network failures, because the return path of the user's traffic would
always end up on its home subnet. The above suggestion where sometimes
the user's traffic is briged and sometimes it is tunneled, would REQUIRE
the WTP and the AC to be on the same subnet - which conflicts with the
"Interconnection Objective". Further, one must assume that there are
functions that reside in the AC that are much more than just "tunnel
termination", and if this is the case these functions are lost when you
resort to brige mode.

If redundancy/resiliency is required, then it must be provided in the
CAPWAP protocol through some other means.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
	Sent: Thursday, June 16, 2005 5:54 AM
	To: Michael Montemurro; Pat Calhoun; [email-masked]
	Subject: RE: [Capwap] Support for Traffic Separation

	Mike,

	To make sure I am clear: by "bridge" I was referring to the
Integration Services -  bridging between 802.11 and 802.3.

	All management frames (security, QoS, etc.) should be handle by
the AC.

	Giving the operator / customer the freedom to run the IS
function in AC or WTP is important and as far as I can tell doesn't
break the CAPWAP model.

	Why it's important: well take #1 for example, if customer wishes
to session to travel along the shorter path between peers, or maintain
existing voice call when AC experience a failover and perform reboot
(but new session or roaming obviously).

	Emek

________________________________

	From: Michael Montemurro [mailto:[email-masked]]

	Sent: Thursday, June 16, 2005 3:35 PM
	To: Sadot, Emek (Emek); Pat Calhoun; [email-masked]
	Subject: RE: [Capwap] Support for Traffic Separation

	Emek,

	I just want to get clarification on your response. You believe
there are four possibilities:

	    1) Split MAC - Bridge at WTP

	    2) Split MAC - Bridge at AC

	    3) Local MAC - Bridge at WTP

	    4) Local MAC - Bridge at AC

	I'd just like to understand how you envision case 1).  What type
of functionality would you envision would terminate at the AC? Could you
be more specific on how you would handle WLAN management frames,
security, and QoS in that case?

	Thanks,

	    Mike

	Michael Montemurro
	Director, Advanced Technology and Standards
	Chantry Networks, A Siemens Company
	1900 Minnesota Ct, Suite 125
	Mississauga, ON, CANADA.
	T: 905-363-6413
	F: 905-567-9900
	E: [email-masked]

---

From: "Pat Calhoun" <[email-masked]>
Date: Fri, 17 Jun 2005 05:53:21 -0700

Darren,
 
I actually believe that CAPWAP should focus on 2 and 3. I do believe that
there are situations where option 3 makes sense, such as when centralized
monitoring and configuration of the WTPs is desired, however local bridging
is required. Imagine a scenario where the link between the WTP and the AC is
constrained and therefore cannot sustain that all traffic be sent to the AC.
One such example would be a retail environment, where every store has a few
APs, but these are all centrally managed, while the traffic is locally
bridged. Obviously option 2 is required for all other circumstances.
 
My issue with mandating options 2 and 4, is that from a user standpoint
there are identical - and therefore the only convenience that we've created
is for the implementors of the WTPs. However, from a feature/function
standpoint, they would end up being identical in nature - and if this is the
case, I honestly don't understand why the WG should focus on creating two
separate solutions to meet the exact same goal.

Pat Calhoun

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Darren Loher
Sent: Thursday, June 16, 2005 4:45 PM
To: Inderpreet Singh; Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

I agree that #2-4 are required scenarios.  I am not sure that #1 is
required.  If "bridge" means the IS function, #1 would be in conflict with
the recent error correction/update of the taxonomy document.

When the IS function is implemented at the WTP, the WTP must be a local MAC
WTP.  However, in a local MAC scenario the CAPWAP protocol must still permit
tunneling or not tunneling user traffic to an AC.  A particular WTP device
may not support this function, but the CAPWAP protocol MUST allow it (IMHO).
This would be compatible with the new update/error correction to the
taxonomy document and gives flexibility for implementers to create traffic
separation if they choose in split and local MAC modes.

-Darren

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Inderpreet Singh
Sent: Thursday, June 16, 2005 4:02 PM
To: Sadot, Emek (Emek); [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

>>"Further, one must assume that there are functions that reside in the AC
that are much more than 

>>so if that's your argument then the counter argument would be: how these
functions being materialized 

>>in Local MAc arch?

If I am not mistaken, this discussion has let to two interpretations of the
word "bridging" as well.

1.	Emek understands bridging as 802.11 to 802.3 conversion.  Which is
technically correct, but really confined definition in our context.  I think
it would be useful to term in 802.11 MAC termination rather than simply
bridging. 

2.	Pat, Mike and I believe that bridging in this context has to do with
bridging the user traffic to the local physical interface.  Usually this is
Ethernet in the WTP case.  Non-bridging would be where the traffic is
tunneled to the AC. 

So I agree, if you bridge locally (ie. if the 802.11 MAC is terminated
Locally and then the resulting 802.3 packets are bridged to the local
physical interface), then it is possible for example to lose the
functionality of L3 roaming of the client.  However, in certain scenarios of
deployments where this function/feature is not needed, local bridging is
quite useful.

Thanks

Inderpreet

  _____  

> Giving the operator / customer the freedom to run the IS function in AC or
WTP is important and as far as I can tell doesn't 

> break the CAPWAP model. Why it's important: well take #1 for example, if
customer wishes to session to travel along 

> the shorter path between peers, or maintain existing voice call when AC
experience a failover and perform reboot (but new 

> session or roaming obviously)."

Emek, I don't see how this can be achieved. A user's end device has a single
IP address. One really cannot split the forwarding of user traffic based on
the relative priority of the traffic or based on network failures, because
the return path of the user's traffic would always end up on its home
subnet. The above suggestion where sometimes the user's traffic is briged
and sometimes it is tunneled, would REQUIRE the WTP and the AC to be on the
same subnet - which conflicts with the "Interconnection Objective". Further,
one must assume that there are functions that reside in the AC that are much
more than just "tunnel termination", and if this is the case these functions
are lost when you resort to brige mode.

If redundancy/resiliency is required, then it must be provided in the CAPWAP
protocol through some other means.

Pat Calhoun

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Sadot, Emek (Emek)
Sent: Thursday, June 16, 2005 5:54 AM
To: Michael Montemurro; Pat Calhoun; [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

Mike,

To make sure I am clear: by "bridge" I was referring to the Integration
Services -  bridging between 802.11 and 802.3.

All management frames (security, QoS, etc.) should be handle by the AC.

Giving the operator / customer the freedom to run the IS function in AC or
WTP is important and as far as I can tell doesn't break the CAPWAP model.

Why it's important: well take #1 for example, if customer wishes to session
to travel along the shorter path between peers, or maintain existing voice
call when AC experience a failover and perform reboot (but new session or
roaming obviously).

Emek

  _____  

Emek,

I just want to get clarification on your response. You believe there are
four possibilities:

I'd just like to understand how you envision case 1).  What type of
functionality would you envision would terminate at the AC? Could you be
more specific on how you would handle WLAN management frames, security, and
QoS in that case?

Thanks,

    Mike

Michael Montemurro