Capwap Mailing List: RE: Proposed Text for Issue 53

[Pat Calhoun (pacalhou) (pcalhoun]

This can be provided through the existing statistics interface in the
protocol. If implementations rather use this, they can. I believe per
packet is required for finer control.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

 

> -----Original Message-----
> From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com] 
> Sent: Wednesday, April 05, 2006 5:33 PM
> To: Bob O'Hara (boohara); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Bob,
> 
> I will accept that there is an AC implementation for per data 
> packet processing. 
> 
> I still prefer that the CAPWAP protocol aggregate measurement 
> information for periodic exchange. 
> 
> Saravanan
> 
> 
>  
> 
> -----Original Message-----
> From: Bob O'Hara (boohara) [mailto:boohara [at] cisco.com]
> Sent: Wednesday, April 05, 2006 10:15 PM
> To: capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> For those AC implementations that want to use per packet data 
> for certain operations, aggregation of the data at the WTP as 
> suggested by Abhijit will preclude this.  The assertion by 
> Saravanan that an AC does not process this information is 
> incorrect.  I can point to at least one existing 
> implementation that already does process this information on 
> a per packet basis.
> 
> The current text, with the change I suggested, is the right 
> way to handle this.  If we want to ADD a capability that the 
> WTP can provide aggregation, I have no objection to that.
> 
>  -Bob
>  
> -----Original Message-----
> From: Saravanan Govindan [mailto:Saravanan.Govindan [at] sg.panasonic.com]
> Sent: Tuesday, April 04, 2006 4:49 PM
> To: Abhijit Choudhury; Pat Calhoun (pacalhou); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Hi Abhijit,
> 
> I am in support of your suggestion. It is true that the AC 
> does not process all data packets. Furthermore, I think for 
> greater control, the AC will need information about the 
> congestion level in the WLAN. This could be a derivative of 
> interference and load factor. 
> 
> As for your suggestion, I think measurement/parameter 
> information from the WTP should be sent over the periodic 
> Echo Request messages. The advantage is that header overhead 
> is reduced. 
> 
> I can prepare text for this approach.
> 
> Cheers,
> 
> Saravanan
> 
> 
> 
>  
> 
> -----Original Message-----
> From: Abhijit Choudhury [mailto:Abhijit [at] sinett.com]
> Sent: Wednesday, April 05, 2006 6:52 AM
> To: Pat Calhoun (pacalhou); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Here's another approach...
> 
> RSSI, SNR, and Data Rate are measurements/parameters of the 
> radio channel that are being reported to the AC for finer 
> control.  Carrying them in every data packet on the data 
> channel means some logic or hardware in the AC will have to 
> parse them out of every data packet and send them to the 
> control path (CPU).  Typically not every packet will go to 
> the CPU and so this data will have to be stored and 
> periodically sent to or read by the CPU.  Note that the AC 
> will be possibly dealing with tens to hundreds of WTPs and 
> hence a potentially large number of STAs.  This implies a 
> large amount of per-STA measurement data has to be stored and 
> moved from the data path to the CPU.
> 
> A more reasonable approach is to let the WTP aggregate such 
> data and periodically send it in the control channel to the 
> AC.  Note the WTP has to deal with much much fewer clients - 
> so the storage burden is less. All we'd need is a frame that 
> carries this information to the AC at a specified interval of 
> time.  This period could be configurable.
> 
> Using this approach, we don't need to increase the CAPWAP 
> header every time we need new measurement info. We can retain 
> the current CAPWAP header and flexibly add any measurement 
> information we need by adding it in the control channel. This 
> is particularly important as we move forward to support 
> 802.11n or other
> non-802.11 technlogies. It decouples the CAPWAP header from 
> the measurement data related information.
> 
> Any thoughts on this ?
> 
> 
> Thanks,
>    Abhijit
> 
> 
> 
> 
> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
> Sent: Monday, April 03, 2006 8:45 PM
> To: capwap
> Subject: [Capwap] Proposed Text for Issue 53
> 
> 
> Here is my proposed text for Issue 53, which is the addition of a Data
> Rate In the CAPWAP header.
> 
> Please let me know if you have any comments.
>  
> 4.1.  CAPWAP Transport Header
> 
>    All CAPWAP protocol messages are encapsulated using a common header
>    format, regardless of the CAPWAP control or CAPWAP Data transport
>    used to carry the messages.  However, certain flags are not
>    applicable for a given transport.  Refer to the specific transport
>    section in order to determine which flags are valid.
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |VER| RID |F|L|R|    Frag ID    |            Length             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                           Reserved                            |
> <=== CHANGED!!!
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Payload...  |
>      +-+-+-+-+-+-+-+-+
> 
> [...]
> 4.1.8.  Reserved
> 
>    This 32 bit field is reserved and may be used by a binding specific
>    extension.  Refer to the transport portion of the binding for a
>    specific wireless technology for the definition of this field.
> 
> [...]
> 
> 11.3.2.  CAPWAP Header Reserved field
> 
>    The reserved CAPWAP header field (see figure Section 4.1) is only
>    used with CAPWAP data frames, and it serves two purposes, depending
>    upon the direction of the frame.  For packets from the WTP 
> to the AC,
>    the field uses the format described in Section 11.3.2.1.  However,
>    for frames sent by the AC to the WTP, the format used is 
> described in
>    described in Section 11.3.2.2.
> 
> 11.3.2.1.  IEEE 802.11 Frame Info
> 
>    When an CAPWAP data frame is received from a station over 
> the air, it
>    is encapsulated and this field is used to include radio and PHY
>    specific information associated with the frame.
> 
>    When used with the IEEE 802.11 binding, the field follows the
>    following format:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     RSSI      |     SNR       |           Data Rate           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    RSSI:  RSSI is a signed, 8-bit value.  It is the received signal
>       strength indication, in dBm.
> 
>    SNR:  SNR is a signed, 8-bit value.  It is the signal to 
> noise ratio
>       of the received IEEE 802.11 frame, in dB.
> 
>    Data Rate:  The data rate field is a 16 bit unsigned value.  The
>       contents of the field is set to 1/10th of the data rate of the
>       packet received by the WTP.  For instance, a packet received at
>       5.5Mbps would be set to 55, while 11Mbps would be set to 110.
> 
> 11.3.2.2.  Destination WLANs
> 
>    The Destination WLAN field is used to specify the target 
> WLANs for a
>    given frame, and is only used with broadcast and multicast frames.
>    This field allows the AC to transmit a single broadcast or 
> multicast
>    frame to the WTP, and allows the WTP to perform the necessary frame
>    replication services.  The field uses the following format:
> 
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |              WLAN             |            Reserved           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    WLAN:  This bit field indicates the WLAN ID (see section
>       Section 11.8.1.1) which the WTP will transmit the 
> associated frame
>       on.  For instance, if a multicast packet is to be transmitted on
>       WLANs 1 and 3, bits 1 and 3 of this field would be 
> enabled.  Note
>       this field is to be set to zero for unicast packets and 
> is unused
>       if the WTP is not providing encryption services.
> 
>    Reserved:  This field MUST be set to zero.
>  
>  
> 
> Pat Calhoun
> CTO, Wireless Networking Business Unit
> Cisco Systems
> _________________________________________________________________
> 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
> 
> _________________________________________________________________
> 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
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
>