Capwap Mailing List: RE: Proposed Text for Issue 53

[Bob O'Hara (boohara) (boohara]

The fields in the data packet must be present, filling them with
information may be optional.

 -Bob
 
-----Original Message-----
From: Jim Murphy [mailto:jmurphy [at] trapezenetworks.com] 
Sent: Thursday, April 06, 2006 9:40 PM
To: Dorothy Stanley
Cc: Saravanan Govindan; capwap; Abhijit Choudhury
Subject: Re: [Capwap] Proposed Text for Issue 53

I suggest "optional to implement" for the following reasons.

1. This information is either only a partial view of what the WTP
sees on the air or its transmission is a waste or bandwidth.
I say either, because it depends on the implementation.

It is a partial view if it includes only traffic from stations that
are associated with the WTP. There are many other
packets that the WTP receives that are not sent to the AC because
the stations (including other WTPs) are not associated with the WTP.
These other packets are very interesting to the AC because they
allow the AC to make decisions based on non-associated station
activity. There is a large set of decisions that can only be made
with this additional information.

If, however, the AC receives all the packets that the WTP receives, then
perhaps the AC has all the information the WTP has, but the cost
to the network between the WTP and AC is considerable. In fact,
it may dominate the traffic between WTP and AC.

2. This information is not available to the AC in the local MAC case.
Since data packets are not transmitted to the AC with local MAC, CAPWAP
must support an alternative mechanism.

Therefore, to answer the interesting questions that today's ACs answer,
to use bandwidth efficiently, and to support all the forwarding models
being addressed by CAPWAP, CAPWAP must support the reporting of
aggregated information in the control path as described by Saravanan.

Furthermore, this bandwidth inefficient, superfluous information in the
data path should be optional.

Thanks,

Jim

Dorothy Stanley wrote:
> Puneet,
> 
> Would WTP support of the "sending the phy info in every packet"
capability
> be
> 
> (a) mandatory to implement and optional to configure?  or
> (b) optional to implement?
> 
> Sending the Phy info (RSSI/SNR/Speed) should be optional. By default 
> this info should *NOT* be sent in every CAPWAP data packet. This 
> capability should be negotiated at WTP<->AC handshake time.
> 
> Thanks,
> 
> Dorothy
> 
> 
>     Hi Bob,
> 
>     It seems the real issue is what is the default mode of operation.
> 
>     Summary:
>     ---------
> 
>     Pat/Bob: Carry the phy info in every CAPWAP data pkt as at least 1
>     implementation uses it
>     Abhijit/Saravanan: Carry phy info in control msgs periodically and
>     not in every CAPWAP data frame.
> 
>     My Proposal (Compromise):
>     -------------------------
>     Sending the Phy info (RSSI/SNR/Speed) should be optional. By
default
>     this info should *NOT* be sent in every CAPWAP data packet. This
>     capability should be negotiated at WTP<->AC handshake time.
> 
>     Comments?
> 
>     Thanks.
> 
>     -Puneet
> 
> 
> 
> 
> 
> 
>
------------------------------------------------------------------------
> 
> _________________________________________________________________
> 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