Subject: RE: [Capwap] Support for Traffic Separation

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

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: Inderpreet Singh <[email-masked]>
Date: Thu, 16 Jun 2005 18:02:16 -0400

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

  _____  

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

  _____  

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

---

From: Michael Montemurro <[email-masked]>
Date: Fri, 17 Jun 2005 08:58:34 -0400

I would say agreed that 2-4 are the required scenarios. 
 
I'm not sure how split the MAC and bridge data traffic at the WTP in the
case of #1
 
Cheers,
 
    Mike

  _____  

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

Given the following scenarios:

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

that are much more than 

Thanks

Inderpreet

  _____  

Pat Calhoun

  _____  

Mike,

Emek

  _____  

Emek,

Thanks,

    Mike

Michael Montemurro

---

From: Michael Montemurro <[email-masked]>
Date: Fri, 17 Jun 2005 09:01:37 -0400

Pat, 

I respectfully dissagree with you with grouping together case 4. There is no
reason why you couldn't terminate 802.11 at the WTP and bridge data traffic
to the AC.
 
Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun
Sent: June 17, 2005 8:53 AM
To: 'Darren Loher'; Inderpreet Singh; 'Sadot, Emek (Emek)';
[email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

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

-Darren

  _____  

 

that are much more than 

Thanks

Inderpreet

  _____  

Pat Calhoun

  _____  

Mike,

Emek

  _____  

Emek,

Thanks,

    Mike

Michael Montemurro

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 17 Jun 2005 10:18:42 -0400

Pat,
 
I did read the draft. I just hold a different opinion.
Please see inline.
 
Emek

  _____  

From: Pat Calhoun [mailto:[email-masked]] 
Sent: Friday, June 17, 2005 1:02 AM
To: Sadot, Emek (Emek); 'Michael Montemurro'; [email-masked]
Subject: RE: [Capwap] Support for Traffic Separation

So if you've had a chance to read the taxonomy recommendations document
that I submitted, I think you'll understand that my argument is that
there must be a clear delineation between Split and Local MAC. A WTP
that has all of the MAC, but sends a message to the AC that encapsulates
most of the information found in some 802.11 mac management packet, then
you combine this with tunneling, you end up with something that is
identical in fuctionatlity to a Split MAC architecture... but without
the name.
[Emek] I totally agree. 
 
I think that we should pick two modes of operation, that are distinct
and address a customer need, and then create a standard to address them.

[Emek] I have an issue with the distinct part. I would like to see some
level of flexibility in each mode of operation, and especially the
ability to run the bridging function in the WTP for Split MAC arch.

I interpreter Split MAC as performing 802.11 real-time functions in the
WTP, and since bridging is a parallel function and since I believe that
Split is superior over Local I would like to stress this point.

I see merits in implementing the bridge function at the WTP in Split MAC
arch, since: (a) shortest path between peers, (b) increase solution's
MTBF as end user sessions will be maintained while connection between
WTP and AC is lost or AC reboot. An example: say the AC is in
Enterprise' headquarter in NYC and a WTP(s) are located in London
office, now i am at London office using my wi-fi phone to dial to a
collage of mine at the same office (or a customer in GB), if the
bridging function is implemented at the AC the call will be travel
through the NYC office - doesn't make sense to me.

So i would like to present two discussions issues:

1. Pros and cons of implementing the bridging function in WTP / Split
MAC (I stated mine).

2. What implementation-challenges / protocol-complexity /
functionality-lost a bridging function at the WTP for Split MAC
introduce that would worth shy away from such configuration.

Pat Calhoun

  _____  

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

	Pat, I understand where you are coming from and respect it,
though I respectfully disagree with the definition: tunneling of user
data is Split, while local bridging is Local.
	 
	Emek

  _____  

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

	Emek,
	 
	Note that I disagree with the need for such complexity in the
protocol, and my belief is this confusion stems from the lack of
conclusion in the taxonomy draft. There is simply much more to tunneling
traffic than just the Distribution and Integration Service, so one must
actually be very specific in each case on where every function resides.
My belief is that tunneling of user data is Split, while local bridging
is Local. We have documented this in the Taxonomy Recommendations
document, which I would urge you to comment on. 

	Pat Calhoun

  _____  

		From: Michael Montemurro
[mailto:[email-masked]] 
		Sent: Thursday, June 16, 2005 5:35 AM
		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:

		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

  _____  

			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

			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

  _____  

				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

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 17 Jun 2005 10:44:17 -0400

Darren,
 
Please see inline.
 
Emek

  _____  

From: Darren Loher [mailto:[email-masked]] 
Sent: Friday, June 17, 2005 2:45 AM
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.
[Emek] The taxonomy draft didn't try to define Local / Split (and
Remote) arch rather to describe the observed implementations in the
market.

When the IS function is implemented at the WTP, the WTP must be a local
MAC WTP.  
[Emek] I disagree. In my mind IS function can be implemented at the WTP
in Split MAC - IS and 802.11 real time function at WTP, whereas 802.11
management frame terminated at the AC.

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

  _____  

	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

---

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

Michael,
 
> I don't believe Option 4 requires significant protocol development effort
over Option 2 and Option 3. There are 
> definitely architectures in the taxonomy which conform to this
architecture and they should be addressed in the protocol 
> definition.
Correct, the work is probably not insurmountable. The question comes down to
whether the WG feels like it wants to put in the effort and have a protocol
with the added complexity. 

Pat Calhoun