Subject: RE: RE: [Capwap] to mux or not to mux?

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 10 May 2006 14:10:57 -0700

The issue is that the AC is not generally the edge device, i.e., the
first device that encounters a packet sent from the WTP.  We are not
mandating (and, in fact, cannot mandate) that the AC live in the wiring
closet and connect directly to the WTPs.  Therefore, the packets from
the WTPs pass through an arbitrary number of layer 2 and layer 3 devices
before arriving at the AC.  

It is at one or more, possibly every one, of these existing intermediate
devices that the QoS ACLs are currently applied.  By hiding the
distinction between data and control inside the mux header, we
immediately prevent all of those existing devices from applying QoS to
the CAPWAP protocol control and data transmissions, differentially.  

As has been pointed out in previous postings, there are valid reasons
for desiring to apply this differential QoS to control and data.  The
mux header prevents this and therefore is not a viable solution for
CAPWAP.  If we persist on this path, we will wind up with a protocol
that will find little acceptance.

 -Bob
 
-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2006 12:38 PM
To: Pat Calhoun (pacalhou); capwap
Subject: RE: RE: [Capwap] to mux or not to mux?

Hi Pat,

>> From: Scott G. Kelly [mailto:[email-masked]] 
>> >Currently deployed Internet gear uses these standardized 
>> techniques to implement QoS, and we've heard no compelling 
>> arguments as to why these standards are insufficient for our
purposes.
>
>I disagree with your assessment, and don't believe we have rough
>consensus. 
>
>A packet is received by the AP. The AP will have to mark the outer
>header to replicate the inner header. The AP doesn't have all of the
>complex QoS policies that are required to determine how to deal with
the
>packet - so the best it can do is replication. The edge device will
have
>to police, and optionally remark. It may have a separate set of
policies
>for data vs. control, because the admin knows that control is more
>important.
>
>I honestly don't see how the edge device does this job without knowing
>the difference between a data packet and a control packet.

Actually, I don't agree that the WTP can't enforce QoS policies - that's
an implementation choice, but it's also beside the point.

Your earlier arguments seemed to indicate that intermediate devices need
the UDP header to apply some sort of "QoS ACLs". We saw in discussion on
this list that this is not the case. 

This current comment suggests that some "edge device" may need to
re-mark packets.  Since these packets are tunneled to the AC, the AC
must be the edge device we're talking about here, and if this is true,
I'm not understanding is why the AC can't look at a mux header to make
the decision. Modern NPUs can easily scan 64 bytes into the packet, and
many can go as far as you like.

Are you saying your hardware has some limitation which precludes this?

Scott

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

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

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

---

From: Philip Rakity <[email-masked]>
Date: Wed, 10 May 2006 17:07:56 -0700

Bob,

Good summary.

One point I am a little confused about is how NAT is handled when we  
use different ports etc.  I would have thought that the devices a  
long the way would need to be changed to handle this.  Another ALG.   
Did I miss understand something?

regards,

Philip

> Are you saying your hardware has some limitation which precludes this?

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.