Capwap Mailing List: RE: Proposed Text for Issue 53

[Saravanan Govindan (Saravanan.Govindan]

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:boohara [at] cisco.com] 
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:Saravanan.Govindan [at] sg.panasonic.com] 
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:boohara [at] cisco.com] 
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: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