Subject: RE: [Capwap] Support for Traffic Separation

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

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 07:24:53 -0700

> 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,

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'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

  _____  

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

  _____  

 
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

  _____  

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-00.t
xt>
http://www.capwap.org/draft-calhoun-capwap-lwapp-objectives-comparison-00.tx
t.
 
Comments welcomed!

Pat Calhoun