Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 4 May 2006 16:08:58 -0700

Do you really see a WTP supporting both simultaneously? My thinking is
that the AC knows in advance and simply programs its data forwarding
engine accordingly.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Jim Murphy [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 2:40 PM
> To: Pat Calhoun (pacalhou)
> Cc: capwap
> Subject: Re: [Capwap] Issue 53: Add Data Rate to LWAPP Header
> 
> Pat,
> 
> Looks great. Any chance we can get a payload type in the header?
> It would be nice for a switching system to be able to switch 
> arbitrary payload types (802.11, 802.3, etc.). I think 8 bits 
> from your Reserved field would suffice.
> 
> Thanks,
> 
> Jim
> 
> Pat Calhoun (pacalhou) wrote:
> > All,
> > 
> > The following is a proposed new CAPWAP header format, as a 
> result of 
> > discussions on the list. Comments are most welcomed.
> > 
> > 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
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |VERSION|   RID   | HLEN  |W|F|L|M|          Reserved  
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |          Fragment ID          |     Frag Offset      
>    |Rsv-2|
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                 (optional) Radio MAC Address         
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |            (optional) Wireless Specific Information  
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |                        Payload ....                  
>          |
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >  
> > 4.1.1.  VERSION Field
> >  
> >    A 4 bit field which contains the version of CAPWAP used in this
> >    packet.  The value for this draft is 0.
> >  
> > 4.1.2.  RID Field
> >  
> >    A 5 bit field which contains the Radio ID number for this packet.
> >    WTPs with multiple radios but a single MAC Address use 
> this field to
> >    indicate which radio is associated with the packet.
> >  
> > 4.1.3.  HLEN
> >    Length of CAPWAP tunnel header in 4 byte words. (Similar to IP
> >    header length). This length includes the optional headers.
> > 
> > 4.1.4.  W Bit
> >  
> >    The Wireless 'W' bit is used to specify whether the 
> optional wireless
> >    specific information field is present in the header. A 
> value of one
> >    (1) is used to represent the fact that the optional header is 
> > present.
> > 
> > 4.1.5.  F Bit
> >  
> >    The Fragment 'F' bit indicates whether this packet is a fragment.
> >    When this bit is one (1), the packet is a fragment and MUST be
> >    combined with the other corresponding fragments to reassemble the
> >    complete information exchanged between the WTP and AC.
> >  
> > 4.1.6.  L Bit
> >  
> >    The Not Last 'L' bit is valid only if the 'F' bit is set and
> >    indicates whether the packet contains the last fragment of a
> >    fragmented exchange between WTP and AC.  When this bit is 1, the
> >    packet is not the last fragment.  When this bit is 0, 
> the packet is
> >    the last fragment.
> > 
> > 4.1.7.  M Bit
> >  
> >    The M bit is used to indicate that the Radio MAC Address optional
> >    header is present. This is used to communicate the MAC 
> address of 
> >    the receiving radio when the native wireless packet. This field 
> >    MUST NOT be set to one in packets sent by the AC to the WTP.
> > 
> > 4.1.8.  Reserved
> >  
> >    The 15-bit Reserved field is reserved and set to 0 in 
> this version 
> > of the
> >    CAPWAP protocol.
> >   
> > 4.1.9. Fragment ID
> >  
> >    An 16 bit field whose value is assigned to each group of 
> fragments
> >    making up a complete set.  The fragment ID space is managed
> >    individually for every WTP/AC pair.  The value of Fragment ID is
> >    incremented with each new set of fragments.  The 
> Fragment ID wraps to
> >    zero after the maximum value has been used to identify a set of
> >    fragments.  
> >  
> > 4.1.10. Fragment Offset
> >  
> >    A 13 bit field that indicates where in the payload will this 
> > fragment belong
> >    during re-assembly. This field is valid when the 'F' bit 
> is set to 1.
> > The 
> >    fragment offset is measured in units of 8 octets (64 bits). The 
> > first
> > 
> >    fragment has offset zero. 
> >  
> > 4.1.11.  Reserved-2
> >  
> >    The 3-bit Reserved-2 field is reserved and set to 0 in 
> this version 
> > of the
> >    CAPWAP protocol.
> > 
> > 4.1.12.  Radio MAC Address
> > 
> >    This optional field contains the MAC address of the 
> radio receiving 
> > the
> >    packet. This is useful in packets sent from the WTP to 
> the AC, when 
> > the
> >    native wireless frame format is converted to 802.3 by 
> the WTP. This 
> > field
> >    is only present if the 'M' bit is set.
> > 
> >    The field contains the basic 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
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |    Length     |                  MAC Address
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    Length:  The number of bytes in the MAC Address field. 
> The length 
> > field
> >       is present since new IEEE technologies are using 48 byte MAC 
> > addresses
> > 
> >    MAC Address:  MAC Address of the receiving radio
> > 
> >  
> > 4.1.13.  Wireless Specific Information
> > 
> >    This optional field contains technology specific 
> information that may
> >    be used to carry per packet wireless information. This field is 
> > only present
> >    if the 'W' bit is set.
> > 
> >    The field contains the basic 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
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >      |  Wireless ID  |    Length     |             Data
> >      
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > 
> >    Wireless ID: The wireless binding identifier. The 
> following values 
> > are
> >       defined:
> > 
> >       1 - IEEE 802.11
> > 
> >    Length:  The length of the data field
> > 
> >    Data:  Wireless specific information, whose details are 
> defined in 
> > the
> >       technology specific binding section.
> > 
> > 4.1.14.  Payload
> >  
> >    This field contains the header for a CAPWAP Data Message 
> or CAPWAP
> >    Control Message, followed by the data associated with 
> that message.
> > 
> > [...]
> > 
> > 11.3.2.  CAPWAP Wireless Specific Information
> > 
> >    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
> >  
> > [Rest is identical to -00]
> > 
> > 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

---

From: "Abhijit Choudhury" <[email-masked]>
Date: Thu, 4 May 2006 16:34:22 -0700

Pat,
I agree with Jim. It's easier if the packet header
conveys this information, i.e., what kind of payload
it is carrying.

On a related note, shouldn't RadioId  be part of
the Wireless Specific Information field ?

Thanks,
   Abhijit

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 4:09 PM
To: Jim Murphy
Cc: capwap
Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header

Pat Calhoun

> Looks great. Any chance we can get a payload type in the header? It 
> would be nice for a switching system to be able to switch arbitrary 
> payload types (802.11, 802.3, etc.). I think 8 bits from your Reserved

> field would suffice.

---

From: "Puneet Agarwal" <[email-masked]>
Date: Thu, 4 May 2006 17:11:18 -0700

Hi Pat,

You are right that the payload type would typically be known by the AC -
however this configuration information is typically not known by other
systems (eg you are doing packet mirroring to an remote port analyzer
from a device between AC and WTP - the port analyzer would be unable to
parse the payload effectively as it wouldn't know the payload type).
Hence it is important that the CAPWAP header define the payload (802.3,
802.11 etc) so other network devices can parse the packet if they want
to.

Other comments/questions:

(1) Section 4.1.6: I think intuitively, it would be better if we
re-define the bit as follows

"The 'L' (Last) bit is valid only if the 'F' bit is set and indicates
whether the packet contains the last fragment of a fragmented exchange
between WTP and AC. Specifically:
1: Last fragment
0: Not last fragment"

(2) Section 4.1.12: I assume you meant 48 bits (not bytes).

(3) General: Are each of the optional headers required to be a multiple
of 4 bytes (since the HLEN is required to be a multiple of 4 bytes)? If
not, then do we need to define padding headers?

(4) General: Is there any requirement on the ordering of the optional
headers?

(5) Section 4.1.10: Since you have introduced the notion of fragment
offset, do we then allow for overlapping fragments (eg fragment 0 has
{offset 0, payload length 1000} and fragment 1 has {offset 900, payload
length 600})? My preference would be to disallow this behavior.

(6) General: I assume that there would be a capability mechanism (for
the AC to indicate to the WTP(s)) to specify which optional header the
AC supports.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
Sent: Thursday, May 04, 2006 4:09 PM
To: Jim Murphy
Cc: capwap
Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header

Pat Calhoun

> It would be nice for a switching system to be able to switch arbitrary

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:02:28 -0700

I've created issue 119 for this request.

Pat Calhoun

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:03:06 -0700

I don't think so. I believe any wireless technology could have multiple
radios.

Pat Calhoun

> From: Abhijit Choudhury [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 4:34 PM
> To: Pat Calhoun (pacalhou); Jim Murphy
> Cc: capwap
> I agree with Jim. It's easier if the packet header conveys 
> this information, i.e., what kind of payload it is carrying.
> 
> On a related note, shouldn't RadioId  be part of the Wireless 
> Specific Information field ?
> 
> Thanks,
>    Abhijit
> 
> 
> 
> 
> > >       0                   1                   2           
>         3
> > >       0                   1                   2           
>         3
> > >       0                   1                   2           
>         3
> > >        0                   1                   2          
>          3

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 5 May 2006 07:04:28 -0700

> (1) Section 4.1.6: I think intuitively, it would be better if 
> we re-define the bit as follows
> 
> "The 'L' (Last) bit is valid only if the 'F' bit is set and 
> fragmented exchange between WTP and AC. Specifically:
> 1: Last fragment
> 0: Not last fragment"
> 
> (3) General: Are each of the optional headers required to be 
> a multiple of 4 bytes (since the HLEN is required to be a 
> multiple of 4 bytes)? If not, then do we need to define 
> padding headers?
> 
> (4) General: Is there any requirement on the ordering of the 
> optional headers?
> 
> (5) Section 4.1.10: Since you have introduced the notion of 
> fragment offset, do we then allow for overlapping fragments 
> (eg fragment 0 has {offset 0, payload length 1000} and 
> fragment 1 has {offset 900, payload length 600})? My 
> preference would be to disallow this behavior.
> 
> (6) General: I assume that there would be a capability 
> mechanism (for the AC to indicate to the WTP(s)) to specify 
> which optional header the AC supports.
> 
Puneet, your new issues have been captured under issue 120.

Pat Calhoun