Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport

From: "Scott G. Kelly" <[email-masked]>
Date: Tue, 13 Jun 2006 10:41:46 -0700 (GMT-07:00)

Hi Bob,

boohara wrote:
>
>Scott wrote:
>
>>So if the AC and WTP were to mark control packets 
>>so as to make them distinguishable from data packets 
>>(using one of the marking methods suggested above, 
>>and without relying on client truthfulness), what 
>>problems remain? 
>
>As Pat points out in a separate email, the problem of controlling how
>the WTP marks those packets remains to be solved.  But, that discussion
>can continue in Pat's thread.
>
>Another problem is that the WTP, itself, is not trusted by the network
>to which it is attached.  A widespread example is a network of WLAN
>hotspots.  The WTPs at the hotspot are connected to the AC over a third
>party's network.
>
>In some of those hotspots, the WTP will be local-MAC.  A hotspot user's
>packets from a local-MAC WTP will be able to be inspected at ingress to
>the third party's network, since the 5-tuple is clearly available in
>those packets.  QoS can be applied to those user data packets, without
>requiring any changes to the third party's network equipment.
>
>However, if those same packets are sent to the AC by a split-MAC WTP,
>the third party network will not be able to distinguish control packets
>from data packets, unless they are sent on separate ports.  In the
>CAPWAP packet, the 5-tuple is the same for both control and data.

Keeping in mind that what we are trying to do is ascertain whether premise (4) was correctly formulated, let me re-state that in its original form:

(4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use VLAN tags or 1:1 mappings of  DSCP/802.1q/802.1d mappings

Apparently, what is at issue is the phrase "1:1 mappings of" - if I apply what you've said above to this premise, it seems that this would be an acceptable re-formulation:

(4) many of these elements can only classify traffic based on 5-tuples; they apparently cannot use AC/WTP-provided VLAN tags or DSCP/802.1q/802.1d markings for QoS purposes

Does this reflect your intent?

Thanks,

Scott

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: <[email-masked]>
Date: Tue, 13 Jun 2006 14:04:55 -0700

Colleagues,

It's obvious but we should state that our discussion is strictly limited
to 802.3 VLAN capable AC<->WTP connection with .3 frame size between the
AC and WTP being less or equal to the WTP-STA frame size. Anything such
as wireless would widen the scope beyond what we are talking about here.

Best Regards,
Michael

-----Original Message-----
From: ext Scott G. Kelly [mailto:[email-masked]] 
Sent: Tuesday, June 13, 2006 10:42 AM
To: Bob O'Hara (boohara); capwap
Subject: Re: [Capwap] capwap transport analysis: QoS vs multiport

Hi Bob,

boohara wrote:
>
>Scott wrote:
>
>>So if the AC and WTP were to mark control packets so as to make them 
>>distinguishable from data packets (using one of the marking methods 
>>suggested above, and without relying on client truthfulness), what 
>>problems remain?
>

>CAPWAP packet, the 5-tuple is the same for both control and data.

Keeping in mind that what we are trying to do is ascertain whether
premise (4) was correctly formulated, let me re-state that in its
original form:

(4) many of these elements can only classify traffic based on 5-tuples;
they apparently cannot use VLAN tags or 1:1 mappings of
DSCP/802.1q/802.1d mappings

Apparently, what is at issue is the phrase "1:1 mappings of" - if I
apply what you've said above to this premise, it seems that this would
be an acceptable re-formulation:

(4) many of these elements can only classify traffic based on 5-tuples;
they apparently cannot use AC/WTP-provided VLAN tags or
DSCP/802.1q/802.1d markings for QoS purposes

Thanks,

Scott