Subject: [Capwap] Proposed Text for Issue 53

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 3 Apr 2006 20:44:52 -0700

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

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Tue, 4 Apr 2006 11:54:09 -0700

Pat,

A suggestion for better language defining the value of the Data Rate
field:

Replace only the second sentence with the following:
"The content of the field is a value representing the data rate of the
frame received by the WTP.  The value is in units of 100kbps." 

 -Bob
 
-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Monday, April 03, 2006 8:45 PM
To: capwap
Subject: [Capwap] Proposed Text for Issue 53

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Tue, 4 Apr 2006 15:52:08 -0700

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Saravanan Govindan" <[email-masked]>
Date: Wed, 5 Apr 2006 07:48:57 +0800

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 5 Apr 2006 07:15:03 -0700

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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 5 Apr 2006 15:49:23 -0700

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

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Wed, 5 Apr 2006 17:22:15 -0700

The default mode is not the only issue. As Bob has
pointed out some AC implementations may use per-packet
receive info for value added functionalities.  Some others 
may use transmit info (like number of retries, transmit
rate) to do similar services and prefer that instead
or in addition.  And some may be prefer the WTP to do
the aggregation.  So, now do we keep adding all this
additional fields into the CAPWAP header ?

Based on our current discussion, I would suggest having
extension capabilities in the CAPWAP header. The current
CAPWAP header can be the default header. (Note that we need 
a 6 byte CAPWAP header for AC -> WTP direction as we need 
the WLAN ID field. So, we can also carry RSSI/SNR for free).

Below are some possibilities :

1. We can use the VER (version) field for this .
For example, the current CAPWAP header can be VER 0.
Now if someone needs data rate or other stats, 
we can define different size fields
(2bytes, 6 bytes etc) with the other encodings of VER.
This gives us the flexbility to do carry additional
information if the implementation needs it.
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 0| RID |F|L|R|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Payload....         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0 1| RID |F|L|R|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Data Rate           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Payload...  |
     +-+-+-+-+-+-+-+-+

2. Alternatively, we can use the current R bit as an option 
flag (like L2TP). Data Rate (new D bit) could be a flag
and if set, would indicate a 2 byte field at the end
that carries data rate.

D=0      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|D|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Payload....         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D=1
      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|D|    Frag ID    |            Length             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     RSSI      |     SNR       |           Data Rate           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Payload...  |
     +-+-+-+-+-+-+-+-+

With this approach, we will have the flexibility to carry additional
information if we need it on a per-packet basis, and only the default 
header if we don't need it or are allowing the WTP to aggregate
information.
We will not need to make it mandatory for everyone to carry additional
information.

Comments ?

Thanks,
   Abhijit

-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, April 05, 2006 3:49 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Hi Bob,

Summary:
---------

Comments?

Thanks.

-Puneet

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

 -Bob

-----Original Message-----
From: Saravanan Govindan [mailto:[email-masked]
<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,

Cheers,

Saravanan

-----Original Message-----
From: Abhijit Choudhury [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Wednesday, April 05, 2006 6:52 AM
To: Pat Calhoun (pacalhou); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

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]
<mailto:[email-masked]> ]
Sent: Monday, April 03, 2006 8:45 PM
To: capwap
Subject: [Capwap] Proposed Text for Issue 53

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun
<http://lists.frascone.com/mailman/listinfo/capwap> 

Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap> 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

Archives: http://lists.frascone.com/pipermail/capwap
<http://lists.frascone.com/pipermail/capwap>

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 6 Apr 2006 08:32:50 +0800

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Wed, 5 Apr 2006 18:23:18 -0700

Saravanan,
 
That's how it is now. I am just proposing that
we retain the current format as the default.
And have options to add information if desired.
 
Thanks,
   Abhijit

	-----Original Message-----
	From: Saravanan Govindan
[mailto:[email-masked]] 
	Sent: Wednesday, April 05, 2006 6:16 PM
	To: Abhijit Choudhury; Puneet Agarwal; Bob O'Hara (boohara); Pat
Calhoun (pacalhou); capwap
	Subject: RE: [Capwap] Proposed Text for Issue 53

	Hi Abhijit,

	For clarification, your suggestion is to continue with having
the WLAN ID field in CAPWAP packets for AC -> WTP. However, for CAPWAP
packets for WTP -> AC, your suggestion is to replace WLAN ID field with
the channel measurement information. 

	Is this right? 
	
	Cheers,
	
	Saravanan

	
________________________________

	From: Abhijit Choudhury [mailto:[email-masked]] 
	Sent: Thursday, April 06, 2006 8:22 AM
	To: Puneet Agarwal; Bob O'Hara (boohara); Pat Calhoun
(pacalhou); capwap
	Subject: RE: [Capwap] Proposed Text for Issue 53

	

	

	      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
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	     |0 0| RID |F|L|R|    Frag ID    |            Length
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	     |     RSSI      |     SNR       |           Payload....
|

	      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
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	     |0 1| RID |F|L|R|    Frag ID    |            Length
|
	
	     |     RSSI      |     SNR       |           Data Rate
|

	D=0      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|D|    Frag ID    |            Length
|
	
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	     |     RSSI      |     SNR       |           Payload....
|

	D=1
	      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|D|    Frag ID    |            Length
|
	
	     |     RSSI      |     SNR       |           Data Rate
|

	With this approach, we will have the flexibility to carry
additional

	information if we need it on a per-packet basis, and only the
default 

	We will not need to make it mandatory for everyone to carry
additional

	information.

	Comments ?
	
	Thanks,
	   Abhijit

	
	-----Original Message-----

	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

	-----Original Message-----
	
	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]
	
	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.

	Cheers,
	
	Saravanan

	-----Original Message-----

	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-----

	Here is my proposed text for Issue 53, which is the addition of
a Data Rate In the CAPWAP 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!!!

	[...]
	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.
	
	[...]

	   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.

	   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.

	      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.

	   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.

	
	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
<http://lists.frascone.com/mailman/listinfo/capwap> 

_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit: http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit: http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit: http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap> 

	
_________________________________________________________________
	To unsubscribe or modify your subscription options, please
visit: http://lists.frascone.com/mailman/listinfo/capwap
<http://lists.frascone.com/mailman/listinfo/capwap>

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 5 Apr 2006 19:23:16 -0700

Puneet,

Optional fields in a packet are just plain evil. 

 -Bob
 
-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 3:49 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Hi Bob,

Summary:
---------

Comments?

Thanks.

-Puneet

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 5 Apr 2006 19:25:36 -0700

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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 6 Apr 2006 11:40:53 +0800

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

 -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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Thu, 6 Apr 2006 10:14:30 -0700

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,

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

 -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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Saravanan Govindan" <[email-masked]>
Date: Fri, 7 Apr 2006 09:13:39 +0800

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,

 -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,

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

 -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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 7 Apr 2006 07:51:52 -0700

The fields in the data packet must be present, filling them with
information may be optional.

 -Bob
 
-----Original Message-----
From: Jim Murphy [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 9:40 PM
To: Dorothy Stanley
Cc: Saravanan Govindan; capwap; Abhijit Choudhury
Subject: Re: [Capwap] Proposed Text for Issue 53

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?
> 
> Dorothy
>     Abhijit/Saravanan: Carry phy info in control msgs periodically and
>     not in every CAPWAP data frame.
> 
default
>     capability should be negotiated at WTP<->AC handshake time.
------------------------------------------------------------------------

---

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Fri, 7 Apr 2006 07:53:52 -0700

If this is all that we can agree to, then this would be acceptable.  I
still think that fields appearing or disappearing from a packet header
is a bad path to follow.

 -Bob
 
-----Original Message-----
From: Abhijit Choudhury [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 10: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,

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,

 -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,

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

 -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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 7 Apr 2006 08:33:27 -0700

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

> I will accept that there is an AC implementation for per data 
> packet processing. 
> 
> 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
>  
> 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. 
> 
> information from the WTP should be sent over the periodic 
> Echo Request messages. The advantage is that header overhead 
> is reduced. 
> 
> 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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 7 Apr 2006 08:38:17 -0700

My preference is to not start including optional fields in
The header. I agree with Bob that those are evil. Implementations
oOf Acs are free to ignore the data included in this header, and 
requiring that the WTP include this data at all times is really
not much of a burden.

For ACs that do wish to ignore this data, the statistics mechanism
is used instead.

Pat Calhoun

> 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
> 
> 
> 
>

---

From: "Saravanan Govindan" <[email-masked]>
Date: Tue, 11 Apr 2006 11:23:01 +0800

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:

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,

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,

 -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,

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

 -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,

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

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 12 Apr 2006 23:18:36 -0700

Hi Dorothy,
 
Sorry for the delayed reply (had to take care of uncle sam - ie taxes).
>From my point of view "sending the phy info in every packet" capability
should be optional to implement.
 
Thanks.
 
-Puneet

From: Dorothy Stanley [mailto:[email-masked]] 
Sent: Thursday, April 06, 2006 4:45 PM
To: Saravanan Govindan; Puneet Agarwal
Cc: Abhijit Choudhury; Bob O'Hara (boohara); Pat Calhoun (pacalhou);
capwap
Subject: Re: [Capwap] Proposed Text for Issue 53

Puneet,

Thanks,

Dorothy

	
	Hi Bob,

	Summary:
	---------

	
	Comments?
	
	Thanks.
	
	-Puneet

---

From: "Puneet Agarwal" <[email-masked]>
Date: Wed, 12 Apr 2006 23:23:36 -0700

Hi Bob,

I agree that optional fields are a challenge. One way to get around this
would be to make this feature optional to implement and mark those
fields as reserved for the normal case.

Thanks.

-Puneet

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]] 
Sent: Wednesday, April 05, 2006 7:23 PM
To: Puneet Agarwal; capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Puneet,

 -Bob
 
-----Original Message-----
From: Puneet Agarwal [mailto:[email-masked]]
Sent: Wednesday, April 05, 2006 3:49 PM
To: Bob O'Hara (boohara); capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

Hi Bob,

Summary:
---------

Comments?

Thanks.

-Puneet

-----Original Message-----
From: Bob O'Hara (boohara) [mailto:[email-masked]]
Sent: Wednesday, April 05, 2006 7:15 AM
To: capwap
Subject: RE: [Capwap] Proposed Text for Issue 53

 -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,

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

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

 

      0                   1                   2                   3

[...]
4.1.8.  Reserved

[...]

      0                   1                   2                   3

      0                   1                   2                   3

Pat Calhoun