Subject: RE: [Capwap] Support for Traffic Separation

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Thu, 16 Jun 2005 16:43:35 -0400

Pat,
 
"One really cannot split the forwarding of user traffic based on the
relative priority of the traffic or based on network failures" - I agree
that user data traffic cannot be split, and that wasn't my suggestion. I
suggested that user data traffic will always be bridged at the WTP or
AC.
 
"the return path of the user's traffic would always end up on its home
subnet" - In my suggestion the return path will always hit one of the
two: WTP, if bridging is implemented at the WTP (user's MAC address
associate with the WTP) or AC, if bridging is implemented at the AC
(user's MAC address associate with the AC).
 
"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?
 
Emek

  _____  

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
		Sent: June 15, 2005 4:50 PM
		To: Pat Calhoun; [email-masked]
		Subject: RE: [Capwap] Support for Traffic Separation

		Pat,
		 
		Thanks for your response though it didn't address the
issue I was trying to raise. The problem was at my end - rereading my
question I realize I wasn't clear enough. My apologies. Let me rephrase
my concern though this time in a suggestion manner (rather then
challenging specific proposed protocol).
		 
		In my opinion the CAPWAP protocol shouldn't tie bridging
the user's data traffic function to a specific architecture (split or
local) and be flexible enough to accommodate all four permutations:
Split / MAC & bridging at AC / WTP.
		As part of the initial configuration phase the AC shall
instruct the WTP to either locally bridge data traffic or tunnel to an
AC. 
		 
		Regards,
		Emek

  _____  

		From: Pat Calhoun [mailto:[email-masked]] 
		Sent: Wednesday, June 15, 2005 2:17 PM
		To: Sadot, Emek (Emek); [email-masked]
		Subject: RE: [Capwap] Support for Traffic Separation

		My apologies for the latency in my response.
		 
		Yes, the LWAPP protocol supports what we refer to Local
and Split MAC. In Split MAC, the user's traffic is tunneled between the
WTP and the AC while in Local MAC the data is locally bridged. Draft 02
of the LWAPP draft does not include enough text to cover the Local MAC
case, even though shipping LWAPP products do this today, but we will
have this fixed up in -03.

		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

  _____  

			From: Sadot, Emek (Emek)
[mailto:[email-masked]] 
			Sent: Tuesday, June 07, 2005 12:35 PM
			To: Pat Calhoun; [email-masked]
			Subject: RE: [Capwap] Support for Traffic
Separation

			Pat,
			 
			A question regarding section 2.1.2 Support for
Traffic Separation - author's interpretation of Support for Traffic
Separation: does LWAPP supports an architecture in which the DS is
implemented at the WTP? (avoid tunneling data frames to a control
entity).
			 
			Regards,
			Emek

  _____  

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pat Calhoun
			Sent: Wednesday, June 01, 2005 10:32 AM
			To: [email-masked]
			Subject: [Capwap] LWAPP Self Evaluation draft
posted yesterday

			All,
			 
			As per the protocol submission rules laid out by
the chairs, the authors of the LWAPP protocol submitted a self
evaluation to the I-D draft editors yesterday. I have made the draft
available at
http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-0
0.txt
<http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-
00.txt> .
			 
			Comments welcomed!

			Pat Calhoun
			CTO, Wireless Networking Business Unit
			Cisco Systems

---

From: "Pat Calhoun" <[email-masked]>
Date: Thu, 16 Jun 2005 14:56:44 -0700

"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?
<PRC> So my point was that a Split MAC WTP does not necessarily have the
functions to operate as a Local MAC. So requring it to operate in Local MAC
mode when an AC has failed is not possible. 

Pat Calhoun