Capwap Mailing List: RE: RE: [Capwap] to mux or not to mux?

[Bob O'Hara (boohara) (boohara]

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:s.kelly [at] ix.netcom.com] 
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:s.kelly [at] ix.netcom.com] 
>> >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