Subject: [Capwap] Split-MAC with local bridging at the WTP

From: <[email-masked]>
Date: Wed, 3 Aug 2005 00:17:06 -0700

During the CAPWAP session on Monday, one of the issues that Darren and
the eval team noted as missing in the current SLAPP draft is a mode
where the MAC is split between the WTP and the AC, but the data traffic
is bridged at the WTP (Darren's slide says "local MAC with local
bridging", but this was really a typo and should have read, according to
Darren, "split MAC with local bridging"). This mode is not defined in
the current SLAPP draft because we were not sure what this mode really
meant. It would be good if one of the eval team members presented a
clarification on why they concluded such a mode was required. It would
be even better if we could also get WG discussion/consensus on whether
such a mode is meaningful and is required to be supported in any CAPWAP
protocol. 

Thanks

partha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 3 Aug 2005 04:43:57 -0700

Note I stated the "taxonomy recommendations" draft - not the taxonomy
draft that includes all possible variants.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michael Vakulenko
	Sent: Wednesday, August 03, 2005 3:38 AM
	To: Pat Calhoun (pacalhou)
	Cc: [email-masked]; [email-masked]
	Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

	At 02:27 PM 8/3/2005, Pat Calhoun \(pacalhou\) wrote:

		I agree with Partha that adding this mode simply
complicates the protocol. The Taxonomy Recommendation draft defines two
modes of operation:
		1. Local MAC (locally bridged), and
		2. Split MAC (tunneled)

	I don't recall that taxonomy draft define that split MAC must be
limited to remote bridging. It in fact says that different vendors use
different approaches.
	
	-- Michael V.
	         www.WaveCompass.com

		I think we should stick to those two modes. If the group
feels more would be required, we should understand the application and
use cases - and why the above two groups cannot solve the problems.

		Pat Calhoun
		CTO, Wireless Networking Business Unit
		Cisco Systems

________________________________

			From: [email-masked] [
mailto:[email-masked] <mailto:[email-masked]> ] On
Behalf Of [email-masked]
			
			Sent: Wednesday, August 03, 2005 12:17 AM
			
			To: [email-masked]
			
			Subject: [Capwap] Split-MAC with local bridging
at the WTP

			During the CAPWAP session on Monday, one of the
issues that Darren and the eval team noted as missing in the current
SLAPP draft is a mode where the MAC is split between the WTP and the AC,
but the data traffic is bridged at the WTP (Darren's slide says "local
MAC with local bridging", but this was really a typo and should have
read, according to Darren, "split MAC with local bridging"). This mode
is not defined in the current SLAPP draft because we were not sure what
this mode really meant. It would be good if one of the eval team members
presented a clarification on why they concluded such a mode was
required. It would be even better if we could also get WG
discussion/consensus on whether such a mode is meaningful and is
required to be supported in any CAPWAP protocol. 

			Thanks

			partha

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Fri, 5 Aug 2005 11:41:11 -0400

I agree that adding this mode would complicate the protocol,
nevertheless one can envision a landscape of applications to support
such effort. With your permission I'll name a few:
 
Consider a customer's facilities which span over multiple sites, say a
regional bank, investment or insurance company, or even a campus. Now,
it would only be native to assume that for such customers the AC would
reside at the HQ / main building where the WTP are in the branch offices
/ 
dept. buildings.
a. I would say that one could appreciate the merits of avoiding a voice
call between two people associate to the same WTP to traverse the AC.
b. If the branch office has a leg to the local PSTN, it would consider
better if the call can be routed directly to the PSTN in oppose to hit
the AC first.
 
WiMAX: two topologies (a) 802.11 Mesh networks with a WiMAX as a
backhaul and (b) greenfields WiMAX. I believe that offering an option to
bridge sessions locally in the WiMAX base station rather then to tunnel
the session to the AC and back would better meet real-time application
requirements.
 
Bluetooth: same arguments applies here. The Bluetooth pico cell
communication is confined within the cell by definition.
 
Other then that I find it a bit troubling that the group mandate an
association between the CAPWAP protocol, which is a control protocol,
and the user's data flow.
 
I am not opposing implementing the DS in the AC for Split MAC arch. I
would argue that we should allow the customer to decide what's best for
him, and provide a mechanism to facilitate that by allowing the AC to
program the WTP to either tunnel data packets to the AC or bridge them
locally.
 
Regards,
Emek 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun (pacalhou)
Sent: Wednesday, August 03, 2005 7:28 AM
To: [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

I agree with Partha that adding this mode simply complicates the
protocol. The Taxonomy Recommendation draft defines two modes of
operation:
1. Local MAC (locally bridged), and
2. Split MAC (tunneled)
 
I think we should stick to those two modes. If the group feels more
would be required, we should understand the application and use cases -
and why the above two groups cannot solve the problems.

Pat Calhoun

  _____  

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Wednesday, August 03, 2005 12:17 AM
	To: [email-masked]
	Subject: [Capwap] Split-MAC with local bridging at the WTP

	During the CAPWAP session on Monday, one of the issues that
Darren and the eval team noted as missing in the current SLAPP draft is
a mode where the MAC is split between the WTP and the AC, but the data
traffic is bridged at the WTP (Darren's slide says "local MAC with local
bridging", but this was really a typo and should have read, according to
Darren, "split MAC with local bridging"). This mode is not defined in
the current SLAPP draft because we were not sure what this mode really
meant. It would be good if one of the eval team members presented a
clarification on why they concluded such a mode was required. It would
be even better if we could also get WG discussion/consensus on whether
such a mode is meaningful and is required to be supported in any CAPWAP
protocol. 

	Thanks

	partha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 8 Aug 2005 07:08:41 -0700

Emek,
 
him, 
> and provide a mechanism to facilitate that by allowing the AC to
 
We support this. It's called Split or Local MAC. I think that we need to
limit the number of modes, and given that this scenario (and the rest
below) are addressed in Local MAC mode, then we've addressed these
deployments. I don't believe there is a need to address the same
deployment scenarios in more than one way.
 
Pat Calhoun

	From: Sadot, Emek (Emek) [mailto:[email-masked]] 
	Sent: Friday, August 05, 2005 8:41 AM
	To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
	Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

	Consider a customer's facilities which span over multiple sites,
say a regional bank, investment or insurance company, or even a campus.
Now, it would only be native to assume that for such customers the AC
would reside at the HQ / main building where the WTP are in the branch
offices / 
	dept. buildings.
	a. I would say that one could appreciate the merits of avoiding
a voice call between two people associate to the same WTP to traverse
the AC.
	b. If the branch office has a leg to the local PSTN, it would
consider better if the call can be routed directly to the PSTN in oppose
to hit the AC first.

	 
	Other then that I find it a bit troubling that the group mandate
an association between the CAPWAP protocol, which is a control protocol,
and the user's data flow.
	 
	I am not opposing implementing the DS in the AC for Split MAC
arch. I would argue that we should allow the customer to decide what's
best for him, and provide a mechanism to facilitate that by allowing the
AC to program the WTP to either tunnel data packets to the AC or bridge
them locally.
	 
	Regards,
	Emek 

[mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)

	I think we should stick to those two modes. If the group feels
more would be required, we should understand the application and use
cases - and why the above two groups cannot solve the problems.

	Pat Calhoun

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
		Sent: Wednesday, August 03, 2005 12:17 AM
		To: [email-masked]
		Subject: [Capwap] Split-MAC with local bridging at the
WTP

		During the CAPWAP session on Monday, one of the issues
that Darren and the eval team noted as missing in the current SLAPP
draft is a mode where the MAC is split between the WTP and the AC, but
the data traffic is bridged at the WTP (Darren's slide says "local MAC
with local bridging", but this was really a typo and should have read,
according to Darren, "split MAC with local bridging"). This mode is not
defined in the current SLAPP draft because we were not sure what this
mode really meant. It would be good if one of the eval team members
presented a clarification on why they concluded such a mode was
required. It would be even better if we could also get WG
discussion/consensus on whether such a mode is meaningful and is
required to be supported in any CAPWAP protocol. 

		Thanks

		partha

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Mon, 8 Aug 2005 15:54:37 -0400

Pat,
 
Let me drew you a hypothetical scenario: say a customer deployed ACs
which employed Split MAC architecture in its main cites. After a while
the customer wants to expend its CAPWAP model to remote offices by
installing remote AP (AC stay at the HQs), but to bridge voice calls to
the local PSTN at the remote office.
What your recommendation to this customer would be?
 
Regards,
Emek

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Pat Calhoun (pacalhou)
Sent: Monday, August 08, 2005 10:09 AM
To: Sadot, Emek (Emek); [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

Emek,

 
Pat Calhoun

  _____  

	 

	 

	Regards,
	Emek 

  _____  

	 

	Pat Calhoun

  _____  

		Thanks

		partha

---

From: Michael Montemurro <[email-masked]>
Date: Mon, 8 Aug 2005 16:04:35 -0400

Emek, Pat

One possible solution to this problem would be to take a Local MAC approach,
but configure the tunnel on a logical network basis. For instance, traffic
for one logical network would be bridged locally at the WTP and traffic for
another logical network would be tunnelled to the AC. 
 
The WTP would be configured as Local MAC. Tunnelling would be configured on
a logical network basis.
 
Cheers,
 
    Mike

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun (pacalhou)
Sent: August 8, 2005 10:09 AM
To: Sadot, Emek (Emek); [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

Emek,
 
> I am not opposing implementing the DS in the AC for Split MAC arch. I
would argue that we should allow the customer to decide what's best for him,

> and provide a mechanism to facilitate that by allowing the AC to program
the WTP to either tunnel data packets to the AC or bridge them locally.

We support this. It's called Split or Local MAC. I think that we need to
limit the number of modes, and given that this scenario (and the rest below)
are addressed in Local MAC mode, then we've addressed these deployments. I
don't believe there is a need to address the same deployment scenarios in
more than one way.
 
Pat Calhoun

  _____  

From: Sadot, Emek (Emek) [mailto:[email-masked]] 
Sent: Friday, August 05, 2005 8:41 AM
To: Pat Calhoun (pacalhou); [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

I agree that adding this mode would complicate the protocol, nevertheless
one can envision a landscape of applications to support such effort. With
your permission I'll name a few:
 
Consider a customer's facilities which span over multiple sites, say a
regional bank, investment or insurance company, or even a campus. Now, it
would only be native to assume that for such customers the AC would reside
at the HQ / main building where the WTP are in the branch offices / 
dept. buildings.
a. I would say that one could appreciate the merits of avoiding a voice call
between two people associate to the same WTP to traverse the AC.
b. If the branch office has a leg to the local PSTN, it would consider
better if the call can be routed directly to the PSTN in oppose to hit the
AC first.
 
WiMAX: two topologies (a) 802.11 Mesh networks with a WiMAX as a backhaul
and (b) greenfields WiMAX. I believe that offering an option to bridge
sessions locally in the WiMAX base station rather then to tunnel the session
to the AC and back would better meet real-time application requirements.

Other then that I find it a bit troubling that the group mandate an
association between the CAPWAP protocol, which is a control protocol, and
the user's data flow.
 
I am not opposing implementing the DS in the AC for Split MAC arch. I would
argue that we should allow the customer to decide what's best for him, and
provide a mechanism to facilitate that by allowing the AC to program the WTP
to either tunnel data packets to the AC or bridge them locally.
 
Regards,
Emek 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Pat Calhoun (pacalhou)
Sent: Wednesday, August 03, 2005 7:28 AM
To: [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

I agree with Partha that adding this mode simply complicates the protocol.
The Taxonomy Recommendation draft defines two modes of operation:
1. Local MAC (locally bridged), and
2. Split MAC (tunneled)
 
I think we should stick to those two modes. If the group feels more would be
required, we should understand the application and use cases - and why the
above two groups cannot solve the problems.

Pat Calhoun

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Wednesday, August 03, 2005 12:17 AM
To: [email-masked]
Subject: [Capwap] Split-MAC with local bridging at the WTP

During the CAPWAP session on Monday, one of the issues that Darren and the
eval team noted as missing in the current SLAPP draft is a mode where the
MAC is split between the WTP and the AC, but the data traffic is bridged at
the WTP (Darren's slide says "local MAC with local bridging", but this was
really a typo and should have read, according to Darren, "split MAC with
local bridging"). This mode is not defined in the current SLAPP draft
because we were not sure what this mode really meant. It would be good if
one of the eval team members presented a clarification on why they concluded
such a mode was required. It would be even better if we could also get WG
discussion/consensus on whether such a mode is meaningful and is required to
be supported in any CAPWAP protocol. 

Thanks

partha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 8 Aug 2005 14:39:16 -0700

Deploy Local MAC WTPs at that site. That what our customers are doing -
use a mix/match approach.

Pat Calhoun

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sadot, Emek (Emek)
	Sent: Monday, August 08, 2005 12:55 PM
	To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
	Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

	Pat,
	 
	Let me drew you a hypothetical scenario: say a customer deployed
ACs which employed Split MAC architecture in its main cites. After a
while the customer wants to expend its CAPWAP model to remote offices by
installing remote AP (AC stay at the HQs), but to bridge voice calls to
the local PSTN at the remote office.
	What your recommendation to this customer would be?
	 
	Regards,
	Emek

	To: Sadot, Emek (Emek); [email-masked];

	Emek,
	 
best for him, 
	> and provide a mechanism to facilitate that by allowing the AC
to program the WTP to either tunnel data packets to the AC or bridge
them locally.

	We support this. It's called Split or Local MAC. I think that we
need to limit the number of modes, and given that this scenario (and the
rest below) are addressed in Local MAC mode, then we've addressed these
deployments. I don't believe there is a need to address the same
deployment scenarios in more than one way.
	 
	Pat Calhoun

		From: Sadot, Emek (Emek) [mailto:[email-masked]] 
		Sent: Friday, August 05, 2005 8:41 AM
		To: Pat Calhoun (pacalhou); [email-masked];
[email-masked]
		Subject: RE: [Capwap] Split-MAC with local bridging at
the WTP

		I agree that adding this mode would complicate the
protocol, nevertheless one can envision a landscape of applications to
support such effort. With your permission I'll name a few:
		 
		Consider a customer's facilities which span over
multiple sites, say a regional bank, investment or insurance company, or
even a campus. Now, it would only be native to assume that for such
customers the AC would reside at the HQ / main building where the WTP
are in the branch offices / 
		dept. buildings.
		a. I would say that one could appreciate the merits of
avoiding a voice call between two people associate to the same WTP to
traverse the AC.
		b. If the branch office has a leg to the local PSTN, it
would consider better if the call can be routed directly to the PSTN in
oppose to hit the AC first.
		 
		WiMAX: two topologies (a) 802.11 Mesh networks with a
WiMAX as a backhaul and (b) greenfields WiMAX. I believe that offering
an option to bridge sessions locally in the WiMAX base station rather
then to tunnel the session to the AC and back would better meet
real-time application requirements.
		 
		Bluetooth: same arguments applies here. The Bluetooth
pico cell communication is confined within the cell by definition.
		 
		Other then that I find it a bit troubling that the group
mandate an association between the CAPWAP protocol, which is a control
protocol, and the user's data flow.
		 
		I am not opposing implementing the DS in the AC for
Split MAC arch. I would argue that we should allow the customer to
decide what's best for him, and provide a mechanism to facilitate that
by allowing the AC to program the WTP to either tunnel data packets to
the AC or bridge them locally.
		 
		Regards,
		Emek 

		Subject: RE: [Capwap] Split-MAC with local bridging at
the WTP

		Pat Calhoun

			Thanks

			partha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 8 Aug 2005 14:40:09 -0700

Sure - that an implementation of a CAPWAP WTP - have it support both
based on the SSID (or some other means that should be outside the scope
of the document).

Pat Calhoun

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

	Sent: Monday, August 08, 2005 1:05 PM
	To: Pat Calhoun (pacalhou); Sadot, Emek (Emek);
[email-masked]; [email-masked]
	Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

	Emek, Pat
	
	One possible solution to this problem would be to take a Local
MAC approach, but configure the tunnel on a logical network basis. For
instance, traffic for one logical network would be bridged locally at
the WTP and traffic for another logical network would be tunnelled to
the AC. 
	 
	The WTP would be configured as Local MAC. Tunnelling would be
configured on a logical network basis.
	 
	Cheers,
	 
	    Mike

		Emek,
		 
Split MAC arch. I would argue that we should allow the customer to
decide what's best for him, 
		> and provide a mechanism to facilitate that by allowing
the AC to program the WTP to either tunnel data packets to the AC or
bridge them locally.

		We support this. It's called Split or Local MAC. I think
that we need to limit the number of modes, and given that this scenario
(and the rest below) are addressed in Local MAC mode, then we've
addressed these deployments. I don't believe there is a need to address
the same deployment scenarios in more than one way.
		 
		Pat Calhoun

			From: Sadot, Emek (Emek)
[mailto:[email-masked]] 
			Sent: Friday, August 05, 2005 8:41 AM
			To: Pat Calhoun (pacalhou);
[email-masked]; [email-masked]
			Subject: RE: [Capwap] Split-MAC with local
bridging at the WTP

			I agree that adding this mode would complicate
the protocol, nevertheless one can envision a landscape of applications
to support such effort. With your permission I'll name a few:
			 
			Consider a customer's facilities which span over
multiple sites, say a regional bank, investment or insurance company, or
even a campus. Now, it would only be native to assume that for such
customers the AC would reside at the HQ / main building where the WTP
are in the branch offices / 
			dept. buildings.
			a. I would say that one could appreciate the
merits of avoiding a voice call between two people associate to the same
WTP to traverse the AC.
			b. If the branch office has a leg to the local
PSTN, it would consider better if the call can be routed directly to the
PSTN in oppose to hit the AC first.
			 
			WiMAX: two topologies (a) 802.11 Mesh networks
with a WiMAX as a backhaul and (b) greenfields WiMAX. I believe that
offering an option to bridge sessions locally in the WiMAX base station
rather then to tunnel the session to the AC and back would better meet
real-time application requirements.
			 
			Bluetooth: same arguments applies here. The
Bluetooth pico cell communication is confined within the cell by
definition.
			 
			Other then that I find it a bit troubling that
the group mandate an association between the CAPWAP protocol, which is a
control protocol, and the user's data flow.
			 
			I am not opposing implementing the DS in the AC
for Split MAC arch. I would argue that we should allow the customer to
decide what's best for him, and provide a mechanism to facilitate that
by allowing the AC to program the WTP to either tunnel data packets to
the AC or bridge them locally.
			 
			Regards,
			Emek 

			From: [email-masked]
[mailto:[email-masked]] On Behalf Of Pat Calhoun (pacalhou)
			Sent: Wednesday, August 03, 2005 7:28 AM
			To: [email-masked];
[email-masked]
			Subject: RE: [Capwap] Split-MAC with local
bridging at the WTP

			I think we should stick to those two modes. If
the group feels more would be required, we should understand the
application and use cases - and why the above two groups cannot solve
the problems.

			Pat Calhoun

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of [email-masked]
				Sent: Wednesday, August 03, 2005 12:17
AM
				To: [email-masked]
				Subject: [Capwap] Split-MAC with local
bridging at the WTP

				During the CAPWAP session on Monday, one
of the issues that Darren and the eval team noted as missing in the
current SLAPP draft is a mode where the MAC is split between the WTP and
the AC, but the data traffic is bridged at the WTP (Darren's slide says
"local MAC with local bridging", but this was really a typo and should
have read, according to Darren, "split MAC with local bridging"). This
mode is not defined in the current SLAPP draft because we were not sure
what this mode really meant. It would be good if one of the eval team
members presented a clarification on why they concluded such a mode was
required. It would be even better if we could also get WG
discussion/consensus on whether such a mode is meaningful and is
required to be supported in any CAPWAP protocol. 

				Thanks

				partha

---

From: "Sadot, Emek (Emek)" <[email-masked]>
Date: Tue, 9 Aug 2005 14:01:47 -0400

I would rather see a flexible WTP that can be administered by the AC to
bridge / tunnel user date, in this case a customer would be able to
reuse its gear if shift in customer's architecture is needed.
 
Other then that if you use a mix and match approach, or DS at the WTP,
then the CAPWAP protocol should be able to compensate on the lose of
user's data visibility to the AC, which means that the WTP shall send
info gather from looking at the user's data traffic via the CAPWAP
protocol to the AC.
 
Emek 

  _____  

From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Monday, August 08, 2005 5:39 PM
To: Sadot, Emek (Emek); [email-masked]; [email-masked]
Subject: RE: [Capwap] Split-MAC with local bridging at the WTP

Pat Calhoun

  _____  

	Pat,

	Regards,
	Emek

  _____  

	Emek,

	 
	Pat Calhoun

  _____  

		 

		 

		Regards,
		Emek 

  _____  

		 

		Pat Calhoun

  _____  

			Thanks

			partha

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 9 Aug 2005 11:06:21 -0700

I agree we should allow for a WTP to operate in either the Local or
Split MAC mode - but this should be an implementation of the protocol,
as long as the protocol is capable of supporting it.

Pat Calhoun

	Sent: Tuesday, August 09, 2005 11:02 AM

	I would rather see a flexible WTP that can be administered by
the AC to bridge / tunnel user date, in this case a customer would be
able to reuse its gear if shift in customer's architecture is needed.
	 
	Other then that if you use a mix and match approach, or DS at
the WTP, then the CAPWAP protocol should be able to compensate on the
lose of user's data visibility to the AC, which means that the WTP shall
send info gather from looking at the user's data traffic via the CAPWAP
protocol to the AC.
	 
	Emek 

	Deploy Local MAC WTPs at that site. That what our customers are
doing - use a mix/match approach.

	Pat Calhoun

		Pat,
		 
		Let me drew you a hypothetical scenario: say a customer
deployed ACs which employed Split MAC architecture in its main cites.
After a while the customer wants to expend its CAPWAP model to remote
offices by installing remote AP (AC stay at the HQs), but to bridge
voice calls to the local PSTN at the remote office.
		What your recommendation to this customer would be?
		 
		Regards,
		Emek

		Emek,

		 
		Pat Calhoun

			From: Sadot, Emek (Emek)

			 

			 
			 
			Regards,
			Emek 

			 

			Pat Calhoun

				Thanks

				partha