Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

From: "Tal Anker" <[email-masked]>
Date: Wed, 3 Aug 2005 10:37:39 +0300

Personally I think that for the generality of LWAPP being it a CONTROL protocol it should strive to be media independent on the data plane (obviously the control plane would have a lot to do with the wireless media ....). And if it can be done while allowing both modes - native 802.11 and 802.3 frames, then IMHO its probably the best way to go....
 
Anyway - as you rightfully said - its the WG call... 
 
- Tal

________________________________

From: Pat Calhoun (pacalhou) [mailto:[email-masked]]
Sent: Wed 8/3/2005 7:40 AM
To: Tal Anker; Tal Anker; [email-masked]
Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

Well, obviously the WG needs to decide, but frankly I see this as being no different than say IPv6 or even 802.1q (for those IEEE heads). Changes in protocols require hardware/firmware changes. I believe that sending "periodic" information about data frames is not useful and that in order for the AC to act as an AP, it needs the data on each and every frame. Such things as signal strength, for instance, allows the AC to make predictive mobility decisions and cannot be represented in 802.3 frames.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

________________________________

	From: Tal Anker [mailto:[email-masked]] 
	Sent: Tuesday, August 02, 2005 3:06 PM
	To: Pat Calhoun (pacalhou); Tal Anker; [email-masked]
	Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

	Hi Pat.
	Upgrading the data path is possible if you have, for example, a network processor performing the data path task. If your AC is based on regular ethernet switch built with ASICs for the data path packet processing (common practice), then you can easily upgrade the control plane but not the forwarding plane....(assuming that all the ACs will be based on HW that allows to easily upgrade to various L2 packet formats seems to me like assuming to have some NP-like capabilities in the AC....).
	 
	As for the piggybacking of the "technology specific" data... My intention was to extract this info and send some summary periodically to the AC using the LWAPP control messages and NOT to piggyback the data packets of the 802.3 with this info... Otherwise you would be correct of course that this would not give much benefit. However doing this in the control path and not the data path allows you to define new LWAPP protocol messages/fields for summarizing "technology specific" data as new technologies are introduced...
	 
	As for differentiated services - the QoS portfolio that the AC can provide, is usualy at least as good as what 802.11 can provide... for instance if you use ethernet 802.3 framing from the WTP to the AC you can mark whatever you need on the frame (not to mention if the traffic is IP traffic and you have additional DSCP field). Also if the packet is suppose to traverse another switch on the way to its destination then anyway it will get the QoS that the switch can assign it to the next link towards the destination... Thus I dont see a real benefit in keeping the wireless media original framing... 
	 
	IMHO extending the LWAPP protocol to support the OPTION for using the AC specific link layer format (in most cases it would be 802.3) would be beneficial in the future and would give LWAPP the flexability that it needs in order to comply to the "applicablity to future wireless technologies"...

	- Tal

________________________________

	From: [email-masked] on behalf of Pat Calhoun (pacalhou)
	Sent: Tue 8/2/2005 11:16 PM
	To: Tal Anker; [email-masked]
	Subject: RE: [Capwap] comment about LWAPP and other wireless technologies

	Tal,
	
	Thanks for the e-mail.
	
	I believe that I understand your point, but I would argue that the AC
	will have to be modified to support a new technology, and that upgrading
	the code in the data path is really no more difficult than the control
	path. If an implementation exists that does not allow for upgrade, then
	it is limiting its market.
	
	I would argue that include "technology specific" information piggy
	backed within the LWAPP data frame would be hard to achieve, because we
	cannot predict what this information would end up being. For instance,
	802.11 has the concept of a BSSID, while 802.16 has something different
	(and has additional information). So how would you map 802.11 QoS field
	into a field that may not match with 802.16s?
	
	If one were to need to extend the piggy backed header, then this would
	require changes to the data path anyhow. Further, certain features will
	require changes to the data path, for instance the introduction of
	802.11i centralized encryption requires that the data path perform
	AES-CCMP, and 802.11e requires specific quality of service queuing and
	policing.
	
	So while I understand the point raised, I firmly believe that
	transporting the native frame provides the AC with all of the
	information for the specific technology, and allows it to provide
	differentiated services based on the information present - vs. limiting
	it to what generic information would be in this piggy backed header.
	
	Pat Calhoun
	CTO, Wireless Networking Business Unit
	Cisco Systems

	> -----Original Message-----
	> From: [email-masked]
	> [mailto:[email-masked]] On Behalf Of Tal Anker
	> Sent: Tuesday, August 02, 2005 7:47 AM
	> To: [email-masked]
	> Subject: [Capwap] comment about LWAPP and other wireless technologies
	>
	> Resending this (it seems the first attempt fails...
	> appologies if you receive duplicate copies...).
	>
	> Hi,
	> while going over the LWAPP draft and on the objecives of
	> CAPWAP there seems to be a CAPWAP objective that may not be
	> fully achieved with the current LWAPP spec.
	> The LWAPP specification requires that the 802.11 frames would
	> be encapsulated by the WTP and sent to the AC for processing.
	> The benefit from doing this is having the original info
	> carried in the .11 frame available to the AC.
	> However, this requires the AC to process the native 802.11
	> frames; an operation that will probably be done in some HW
	> component. My concern is that one of the CAPWAP objectives
	> was to be applicable not only to 802.11 but for various
	> wireless technologies. As a result the LWAPP should also be
	> applicable no only for 802.11... (as it indeed states in the
	> beginning of the LWAPP draft). However mandating that the
	> wireless media frames would be sent to the AC in their
	> original format would make this objective harder to
	> achieve... When a new wireless media type would be
	> introduced, the AC would have to be somehow adapted to
	> process the data frames (not only the control frames that can
	> obviously be processed in the AC cpu...).
	> This means either a HW change (or if the AC is using NP then
	> an NP SW upgrade).
	> What seems reasonable to do is to add the OPTION for sending
	> the data frames to the AC using the media type tha tthe WTP
	> is connected to the AC with. Meaning - to convert the frame
	> in the WTP and to send it to the AC for instance using 802.3
	> ethernet frames... This way when a new wireless technology is
	> inroduced to the AC all that needs to be done is updating the
	> SW of the AC.
	>
	> As for loosing the specific media information that was in the
	> 802.11 header - this info can be collected by the WTP and be
	> sent to the AC using LWAPP protocol messages...
	>
	> Supporting both the current LWAPP suggestion (sending the
	> original 802.11 frames to the AC) AND the option to convert
	> to the AC media type will allow LWAPP to comply to the
	> "future wireless technologies" objective...
	>
	> - Tal
	>
	> =====================================================================
	> Tal Anker, PhD.
	> DANSS - Distributed Algorithms, Networking and Secure Systems Group.
	> The School of Engineering and Computer Science, The hebrew
	> University of Jerusalem, Israel.
	>
	>
	>
	> _______________________________________________
	> Capwap mailing list
	> [email-masked]
	> http://mail.frascone.com/mailman/listinfo/capwap
	>
	_______________________________________________
	Capwap mailing list
	[email-masked]
	http://mail.frascone.com/mailman/listinfo/capwap

---

From: Michael Vakulenko <[email-masked]>
Date: Wed, 03 Aug 2005 10:00:30 +0300

I agree with Tal.

Many of non-802.11 wireless technologies to be supported by CAPWAP 
are defined by IEEE802. For example WiMAX is defined in IEEE 802.16. 
These other technologies are by definition interoperable with 
Ethernet (802.3), which belongs to the same family of L2 standards.

Allowing for 802.3 frames in CAPWAP data plane is the most generic 
way to support wireless technologies other than 802.11.

IMHO, support for 802.3 data plane should be mandatory in CAPWAP as 
the most generic 802 method. Tunneling of wireless frames should be 
allowed as an option.

Thanks,

-- Michael V.

At 10:37 AM 8/3/2005, Tal Anker wrote:
>Personally I think that for the generality of LWAPP being it a 
>CONTROL protocol it should strive to be media independent on the 
>data plane (obviously the control plane would have a lot to do with 
>the wireless media ....). And if it can be done while allowing both 
>modes - native 802.11 and 802.3 frames, then IMHO its probably the 
>best way to go....
>
>----------
>Well, obviously the WG needs to decide, but frankly I see this as 
>being no different than say IPv6 or even 802.1q (for those IEEE 
>heads). Changes in protocols require hardware/firmware changes. I 
>believe that sending "periodic" information about data frames is not 
>useful and that in order for the AC to act as an AP, it needs the 
>data on each and every frame. Such things as signal strength, for 
>instance, allows the AC to make predictive mobility decisions and 
>cannot be represented in 802.3 frames.
>
>Pat Calhoun
>----------
>Upgrading the data path is possible if you have, for example, a 
>network processor performing the data path task. If your AC is based 
>on regular ethernet switch built with ASICs for the data path packet 
>processing (common practice), then you can easily upgrade the 
>control plane but not the forwarding plane....(assuming that all the 
>ACs will be based on HW that allows to easily upgrade to various L2 
>packet formats seems to me like assuming to have some NP-like 
>capabilities in the AC....).
>
>As for the piggybacking of the "technology specific" data... My 
>intention was to extract this info and send some summary 
>periodically to the AC using the LWAPP control messages and NOT to 
>piggyback the data packets of the 802.3 with this info... Otherwise 
>you would be correct of course that this would not give much 
>benefit. However doing this in the control path and not the data 
>path allows you to define new LWAPP protocol messages/fields for 
>summarizing "technology specific" data as new technologies are introduced...
>
>As for differentiated services - the QoS portfolio that the AC can 
>provide, is usualy at least as good as what 802.11 can provide... 
>for instance if you use ethernet 802.3 framing from the WTP to the 
>AC you can mark whatever you need on the frame (not to mention if 
>the traffic is IP traffic and you have additional DSCP field). Also 
>if the packet is suppose to traverse another switch on the way to 
>its destination then anyway it will get the QoS that the switch can 
>assign it to the next link towards the destination... Thus I dont 
>see a real benefit in keeping the wireless media original framing...
>
>IMHO extending the LWAPP protocol to support the OPTION for using 
>the AC specific link layer format (in most cases it would be 802.3) 
>would be beneficial in the future and would give LWAPP the 
>flexability that it needs in order to comply to the "applicablity to 
>future wireless technologies"...
>
>
>- Tal
>
>
>
>
>----------
> [<mailto:[email-masked]>mailto:[email-masked]] 
>   On Behalf Of Tal Anker
> <http://mail.frascone.com/mailman/listinfo/capwap>http://mail.frascone.com/mailman/listinfo/capwap
> >
><http://mail.frascone.com/mailman/listinfo/capwap>http://mail.frascone.com/mailman/listinfo/capwap

---

From: Dan Harkins <[email-masked]>
Date: Wed, 03 Aug 2005 03:21:42 -0700

Michael,

  That's a great suggestion. I also think support for 802.3 in the
data plane should be the mandatory mode of CAPWAP.

  Dan.

On Wed, 03 Aug 2005 10:00:30 +0300 you wrote
> --=====================_261995529==.ALT
> Content-Type: text/html; charset="us-ascii"
> 
> <html>
> <body>
> I agree with Tal.<br><br>
> Many of non-802.11 wireless technologies to be supported by CAPWAP are
> defined by IEEE802. For example WiMAX is defined in IEEE 802.16. These
> other technologies are by definition interoperable with Ethernet (802.3),
> which belongs to the same family of L2 standards. <br><br>
> Allowing for 802.3 frames in CAPWAP data plane is the most generic way to
> support wireless technologies other than 802.11. <br><br>
> IMHO, support for 802.3 data plane should be mandatory in CAPWAP as the
> most generic 802 method. Tunneling of wireless frames should be allowed
> as an option.<br><br>
> Thanks,<br><br>
> -- Michael V.<br><br>
> At 10:37 AM 8/3/2005, Tal Anker wrote:<br>
> <blockquote type=cite class=cite cite="">
> <font face="Arial, Helvetica" size=2>Personally I think that for the
> generality of LWAPP being it a CONTROL protocol it should strive to be
> media independent on the data plane (obviously the control plane would
> have a lot to do with the wireless media ....). And if it can be done
> while allowing both modes - native 802.11 and 802.3 frames, then IMHO its
> probably the best way to go....<br>
> </font>&nbsp;<br>
> <font face="Arial, Helvetica" size=2>Anyway - as you rightfully said -
> its the WG call... <br>
> </font>&nbsp;<br>
> <font face="Arial, Helvetica" size=2>- Tal<br>
> </font><br>
> <hr>
> <font face="Tahoma" size=2><b>From:</b> Pat Calhoun (pacalhou)
> [<a href="mailto:[email-masked]" eudora="autourl">
> mailto:[email-masked]</a>]<br>
> <b>Sent:</b> Wed 8/3/2005 7:40 AM<br>
> <b>To:</b> Tal Anker; Tal Anker; [email-masked]<br>
> <b>Subject:</b> RE: [Capwap] comment about LWAPP and other wireless
> technologies<br>
> </font><br>
> <font face="Arial, Helvetica" size=2 color="#0000FF">Well, obviously the
> WG needs to decide, but frankly I see this as being no different than say
> IPv6 or even 802.1q (for those IEEE heads). Changes in protocols require
> hardware/firmware changes. I believe that sending &quot;periodic&quot;
> information about data frames is not useful and that in order for the AC
> to act as an AP, it needs the data on each and every frame. Such things
> as signal strength, for instance, allows the AC to make predictive
> mobility decisions and cannot be represented in 802.3 frames.<br>
> </font><br>
> <font size=2>Pat Calhoun<br>
> CTO, Wireless Networking Business Unit<br>
> Cisco Systems<br>
> </font>&nbsp;<br><br>
> 
> <dl><hr>
> 
> <dd><font face="Tahoma" size=2>From:</b> Tal Anker
> [<a href="mailto:[email-masked]" eudora="autourl">
> mailto:[email-masked]</a>] <br>
> 
> <dd>Sent:</b> Tuesday, August 02, 2005 3:06 PM<br>
> 
> <dd>To:</b> Pat Calhoun (pacalhou); Tal Anker; [email-masked]<br>
> 
> <dd>Subject:</b> RE: [Capwap] comment about LWAPP and other wireless
> technologies<br>
> </font><br>
> 
> <dd><font face="Arial, Helvetica" size=2>Hi Pat.<br>
> 
> <dd>Upgrading the data path is possible if you have, for example, a
> network processor performing the data path task. If your AC is based on
> regular ethernet switch built with ASICs for the data path packet
> processing (common practice), then you can easily upgrade the control
> plane but not the forwarding plane....(assuming that all the ACs will be
> based on HW that allows to easily upgrade to various L2 packet formats
> seems to me like assuming to have some NP-like capabilities in the
> AC....).<br>
> </font>
> <dd>&nbsp;<br>
> 
> <dd><font face="Arial, Helvetica" size=2>As for the piggybacking of the
> &quot;technology specific&quot; data... My intention was to extract this
> info and send some summary periodically to the AC using the LWAPP control
> messages and NOT to piggyback the data packets of the 802.3 with this
> info... Otherwise you would be correct of course that this would not give
> much benefit. However doing this in the control path and not the data
> summarizing &quot;technology specific&quot; data as new technologies are
> introduced...<br>
> </font>
> <dd>&nbsp;<br>
> 
> <dd><font face="Arial, Helvetica" size=2>As for differentiated services -
> the QoS portfolio that the AC can provide, is usualy at least as good as
> what 802.11 can provide... for instance if you use ethernet 802.3 framing
> from the WTP to the AC you can mark whatever you need on the frame (not
> to mention if the traffic is IP traffic and you have additional DSCP
> field). Also if the packet is suppose to traverse another switch on the
> way to its destination then anyway it will get the QoS that the switch
> can assign it to the next link towards the destination... Thus I dont see
> a real benefit in keeping the wireless media original framing... <br>
> </font>
> <dd>&nbsp;<br>
> 
> <dd><font face="Arial, Helvetica" size=2>IMHO extending the LWAPP
> protocol to support the OPTION for using the AC specific link layer
> format (in most cases it would be 802.3) would be beneficial in the
> future and would give LWAPP the flexability that it needs in order to
> comply to the &quot;applicablity to future wireless
> technologies&quot;...<br>
> </font>
> <dd>&nbsp;<br>
> 
> <dd>&nbsp;<br>
> 
> <dd>- Tal<br>
> 
> <dd>&nbsp;<br><br>
> 
> <dd>&nbsp;<br>
> <hr>
> 
> <dd><font face="Tahoma" size=2>From:</b> [email-masked] on
> behalf of Pat Calhoun (pacalhou)<br>
> 
> <dd>Sent:</b> Tue 8/2/2005 11:16 PM<br>
> 
> <dd>To:</b> Tal Anker; [email-masked]<br>
> 
> <dd>Subject:</b> RE: [Capwap] comment about LWAPP and other wireless
> technologies<br>
> </font><br>
> 
> <dd><font size=2>Tal,<br><br>
> 
> <dd>Thanks for the e-mail.<br><br>
> 
> <dd>I believe that I understand your point, but I would argue that the
> AC<br>
> 
> <dd>will have to be modified to support a new technology, and that
> upgrading<br>
> 
> <dd>the code in the data path is really no more difficult than the
> control<br>
> 
> <dd>path. If an implementation exists that does not allow for upgrade,
> then<br>
> 
> <dd>it is limiting its market.<br><br>
> 
> <dd>I would argue that include &quot;technology specific&quot;
> information piggy<br>
> 
> <dd>backed within the LWAPP data frame would be hard to achieve, because
> we<br>
> 
> <dd>cannot predict what this information would end up being. For
> instance,<br>
> 
> <dd>802.11 has the concept of a BSSID, while 802.16 has something
> different<br>
> 
> <dd>(and has additional information). So how would you map 802.11 QoS
> field<br>
> 
> <dd>into a field that may not match with 802.16s?<br><br>
> 
> <dd>If one were to need to extend the piggy backed header, then this
> would<br>
> 
> <dd>require changes to the data path anyhow. Further, certain features
> will<br>
> 
> <dd>require changes to the data path, for instance the introduction
> of<br>
> 
> <dd>802.11i centralized encryption requires that the data path
> perform<br>
> 
> <dd>AES-CCMP, and 802.11e requires specific quality of service queuing
> and<br>
> 
> <dd>policing.<br><br>
> 
> <dd>So while I understand the point raised, I firmly believe that<br>
> 
> <dd>transporting the native frame provides the AC with all of the<br>
> 
> <dd>information for the specific technology, and allows it to
> provide<br>
> 
> <dd>differentiated services based on the information present - vs.
> limiting<br>
> 
> <dd>it to what generic information would be in this piggy backed
> header.<br><br>
> 
> <dd>Pat Calhoun<br>
> 
> <dd>CTO, Wireless Networking Business Unit<br>
> 
> <dd>Cisco Systems<br><br>
> <br><br>
> 
> <dd>&gt; -----Original Message-----<br>
> 
> <dd>&gt; From: [email-masked]<br>
> 
> <dd>&gt;
> [<a href="mailto:[email-masked]">
> mailto:[email-masked]</a>] On Behalf Of Tal Anker<br>
> 
> <dd>&gt; Sent: Tuesday, August 02, 2005 7:47 AM<br>
> 
> <dd>&gt; To: [email-masked]<br>
> 
> <dd>&gt; Subject: [Capwap] comment about LWAPP and other wireless
> technologies<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; Resending this (it seems the first attempt fails...<br>
> 
> <dd>&gt; appologies if you receive duplicate copies...).<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; Hi,<br>
> 
> <dd>&gt; while going over the LWAPP draft and on the objecives of<br>
> 
> <dd>&gt; CAPWAP there seems to be a CAPWAP objective that may not be<br>
> 
> <dd>&gt; fully achieved with the current LWAPP spec.<br>
> 
> <dd>&gt; The LWAPP specification requires that the 802.11 frames
> would<br>
> 
> <dd>&gt; be encapsulated by the WTP and sent to the AC for
> processing.<br>
> 
> <dd>&gt; The benefit from doing this is having the original info<br>
> 
> <dd>&gt; carried in the .11 frame available to the AC.<br>
> 
> <dd>&gt; However, this requires the AC to process the native 802.11<br>
> 
> <dd>&gt; frames; an operation that will probably be done in some HW<br>
> 
> <dd>&gt; component. My concern is that one of the CAPWAP objectives<br>
> 
> <dd>&gt; was to be applicable not only to 802.11 but for various<br>
> 
> <dd>&gt; wireless technologies. As a result the LWAPP should also be<br>
> 
> <dd>&gt; applicable no only for 802.11... (as it indeed states in
> the<br>
> 
> <dd>&gt; beginning of the LWAPP draft). However mandating that the<br>
> 
> <dd>&gt; wireless media frames would be sent to the AC in their<br>
> 
> <dd>&gt; original format would make this objective harder to<br>
> 
> <dd>&gt; achieve... When a new wireless media type would be<br>
> 
> <dd>&gt; introduced, the AC would have to be somehow adapted to<br>
> 
> <dd>&gt; process the data frames (not only the control frames that
> can<br>
> 
> <dd>&gt; obviously be processed in the AC cpu...).<br>
> 
> <dd>&gt; This means either a HW change (or if the AC is using NP
> then<br>
> 
> <dd>&gt; an NP SW upgrade).<br>
> 
> <dd>&gt; What seems reasonable to do is to add the OPTION for
> sending<br>
> 
> <dd>&gt; the data frames to the AC using the media type tha tthe WTP<br>
> 
> <dd>&gt; is connected to the AC with. Meaning - to convert the frame<br>
> 
> <dd>&gt; in the WTP and to send it to the AC for instance using
> 802.3<br>
> 
> <dd>&gt; ethernet frames... This way when a new wireless technology
> is<br>
> 
> <dd>&gt; inroduced to the AC all that needs to be done is updating
> the<br>
> 
> <dd>&gt; SW of the AC.<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; As for loosing the specific media information that was in
> the<br>
> 
> <dd>&gt; 802.11 header - this info can be collected by the WTP and
> be<br>
> 
> <dd>&gt; sent to the AC using LWAPP protocol messages...<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; Supporting both the current LWAPP suggestion (sending the<br>
> 
> <dd>&gt; original 802.11 frames to the AC) AND the option to convert<br>
> 
> <dd>&gt; to the AC media type will allow LWAPP to comply to the<br>
> 
> <dd>&gt; &quot;future wireless technologies&quot; objective...<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; - Tal<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt;
> =====================================================================<br>
> 
> <dd>&gt; Tal Anker, PhD.<br>
> 
> <dd>&gt; DANSS - Distributed Algorithms, Networking and Secure Systems
> Group.<br>
> 
> <dd>&gt; The School of Engineering and Computer Science, The hebrew<br>
> 
> <dd>&gt; University of Jerusalem, Israel.<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt;<br>
> 
> <dd>&gt; _______________________________________________<br>
> 
> <dd>&gt; Capwap mailing list<br>
> 
> <dd>&gt; [email-masked]<br>
> 
> <dd>&gt;
> <a href="http://mail.frascone.com/mailman/listinfo/capwap">
> http://mail.frascone.com/mailman/listinfo/capwap</a><br>
> 
> <dd>&gt;<br>
> 
> <dd>_______________________________________________<br>
> 
> <dd>Capwap mailing list<br>
> 
> <dd>[email-masked]<br>
> 
> <dd><a href="http://mail.frascone.com/mailman/listinfo/capwap">
> http://mail.frascone.com/mailman/listinfo/capwap</a><br>
> </font>
> </dl></blockquote></body>
> </html>
> 
> --=====================_261995529==.ALT--
>