Subject: [Capwap] Variable Length headers

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 11 Apr 2006 09:40:57 -0700

All,

As a result of issue 53, two requests have come in to make the CAPWAP
headers
variable in length, using a bit in the header to indicate additional
data.

I'd like to get a sense from the group on whether there are objections
to 
changing the text for issue 53 to change the CAPWAP header to make all
of the
RF related info optional.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Monday, April 10, 2006 8:23 PM
> To: Abhijit Choudhury; Bob O'Hara (boohara); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Hi Abhijit,
> 
> I understand your suggestion below. 
> 
> However, following from the point Jim made earlier, 
> per-data-packet statistics only applies to split-MAC WTP. It 
> does not apply to local-MAC WTPs where not all data packets 
> reach the AC. 
> 
> Aggregated statistics, on the other hand, can be used for 
> both split-MAC and local-MAC WTPs. Since this covers both 
> types of WTPs that CAPWAP will be used for, I think we should 
> use this as the default. 
> 
> My suggestion is to have the Echo Request carry aggregated 
> statistics as default and have the RSSI/SNR header fields as 
> optional. 
> 
> Cheers,
> 
> Saravanan
> 
> 
> 
> 
> -----Original Message-----
> From: Abhijit Choudhury [mailto:[email-masked]]
> Sent: Friday, April 07, 2006 1:18 PM
> To: Saravanan Govindan; Bob O'Hara (boohara); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Bob, Saravanan:
> 
> Here's what I'd suggest.  Since the current CAPWAP spec 
> already supports carrying RSSI/SNR in the base CAPWAP header 
> (in the 6 bytes), we can make transmission of per-packet 
> measurement the default mode, and the exchange of aggregated 
> information from the WTP an "optional to implement" mode.  
> However, we will use an extension of the base CAPWAP header, 
> say with the D bit as explained in my earlier email, to 
> extend the CAPWAP header by
> 2 more bytes to carry additional per-packet info like the data rate.
> 
> This way vendors who want to use per-packet information can 
> do so, without burdening others who decide to implement the 
> option of the WTP sending aggregated information.  I think 
> this is a reasonable compromise that satisfactorily resolves 
> Issue 53, while allowing for flexibility.
> 
> Comments ?
> 
> Thanks,
>    Abhijit
> 
> 
> 
> 
> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]]
> Sent: Thursday, April 06, 2006 6:14 PM
> To: Bob O'Hara (boohara); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> 
> Bob,
> 
> I understand from your note that per data packet measurement is the
> basis for real time AC processing. My support for aggregated 
> measurement
> exchange is based on efficiency considerations. Having said this, I do
> not want to exclude one or the other - the exchanges so far show both
> make for valuable additions to CAPWAP.
> 
> I think we can move forward now maintaining / incorporating both types
> of exchanges in to the CAPWAP specs.
> 
> Saravanan
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Bob O'Hara (boohara) [mailto:[email-masked]] 
> Sent: Friday, April 07, 2006 1:15 AM
> To: Saravanan Govindan; capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Saranavan,
> 
> As I said in another email earlier in the thread than the one to which
> you responded, I do not have an objection to adding the reporting of
> aggregated information in a status report or other message.  I do not
> want to lose the ability to deal with or have access to the real time
> information in the AC, on a packet by packet basis.
> 
> Why do you object to enabling a function such as real time 
> processing of
> the packet RSSI and SNR?
> 
>  -Bob
>  
> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> Sent: Wednesday, April 05, 2006 8:41 PM
> To: Bob O'Hara (boohara); capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> Bob,
> 
> Without going in to pseudo-judicial rhetoric, I think we need 
> to look at
> what is needed for the CAPWAP protocol. 
> 
> >From the exchanges so far, we see that measurement information can be
> exchanged on a per data packet basis or on an aggregated 
> basis. We have
> seen the advantages of exchanging then on aggregated basis. In the
> spirit of quick resolution, I suggest we select one as the 
> default mode
> for CAPWAP and have the other as an additional feature. I believe this
> was suggested earlier also. 
> 
> Saravanan
> 
> 
> 
> 
> -----Original Message-----
> From: Bob O'Hara (boohara) [mailto:[email-masked]] 
> Sent: Thursday, April 06, 2006 10:26 AM
> To: Saravanan Govindan; capwap
> Subject: RE: [Capwap] Proposed Text for Issue 53
> 
> So, your preference is to remove functionality that is already in a
> product available today, by eliminating this capability from the
> protocol.  Given Moore's law advancement of processing 
> capability, this
> seems a bit short sighted. 
> 
> 
>  -Bob
>  
> -----Original Message-----
> From: Saravanan Govindan [mailto:[email-masked]] 
> 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:[email-masked]] 
> 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:[email-masked]] 
> 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:[email-masked]] 
> 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:[email-masked]] 
> 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
> 
> _________________________________________________________________
> 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