Re: Proposed Text for Issue 53
From: Jim Murphy (jmurphytrapezenetworks.com)
Date: Thu, 6 Apr 2006 21:39:40 -0700 (PDT)
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


Results generated by Tiger Technologies using MHonArc.