| Re: Proposed Text for Issue 53 | <– Date –> <– Thread –> |
|
From: Jim Murphy (jmurphy |
|
| Date: Thu, 6 Apr 2006 21:39:40 -0700 (PDT) | |
I suggest "optional to implement" for the following reasons.
Thanks,
Jim
Dorothy Stanley wrote:
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
- RE: Proposed Text for Issue 53, (continued)
- RE: Proposed Text for Issue 53 Abhijit Choudhury, April 5 2006
- RE: Proposed Text for Issue 53 Saravanan Govindan, April 5 2006
-
RE: Proposed Text for Issue 53 Saravanan Govindan, April 5 2006
-
Re: Proposed Text for Issue 53 Dorothy Stanley, April 6 2006
- Re: Proposed Text for Issue 53 Jim Murphy, April 6 2006
-
Re: Proposed Text for Issue 53 Dorothy Stanley, April 6 2006
- RE: Proposed Text for Issue 53 Abhijit Choudhury, April 5 2006
- RE: Proposed Text for Issue 53 Bob O'Hara (boohara), April 5 2006
- RE: Proposed Text for Issue 53 Bob O'Hara (boohara), April 5 2006
- RE: Proposed Text for Issue 53 Saravanan Govindan, April 5 2006
Results generated by Tiger Technologies using MHonArc.