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

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

But do you believe that WTPs would send both simultaneously?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Abhijit Choudhury [mailto:[email-masked]] 
> Sent: Thursday, May 04, 2006 4:34 PM
> To: Pat Calhoun (pacalhou); Jim Murphy
> Cc: capwap
> Subject: RE: [Capwap] Issue 53: Add Data Rate to LWAPP Header
> 
> 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
> 
> 
> 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
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Jim Murphy <[email-masked]>
Date: Thu, 04 May 2006 18:41:37 -0700

If the WTP supported both 802.11 and 802.16. 802.16
encapsulates 802.3 frames.

Thanks,

Jim