| RE: Issue 53: Add Data Rate to LWAPP Header | <– Date –> <– Thread –> |
From: Abhijit Choudhury (Abhijit sinett.com)
|
|
| Date: Thu, 4 May 2006 16:34:24 -0700 (PDT) | |
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:pcalhoun [at] cisco.com] 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:jmurphy [at] trapezenetworks.com] > 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
-
Issue 53: Add Data Rate to LWAPP Header Pat Calhoun (pacalhou), May 1 2006
- Re: Issue 53: Add Data Rate to LWAPP Header Jim Murphy, May 4 2006
- RE: Issue 53: Add Data Rate to LWAPP Header Pat Calhoun (pacalhou), May 4 2006
- RE: Issue 53: Add Data Rate to LWAPP Header Abhijit Choudhury, May 4 2006
-
RE: Issue 53: Add Data Rate to LWAPP Header Pat Calhoun (pacalhou), May 4 2006
- Re: Issue 53: Add Data Rate to LWAPP Header Jim Murphy, May 4 2006
- RE: Issue 53: Add Data Rate to LWAPP Header Puneet Agarwal, May 4 2006
- RE: Issue 53: Add Data Rate to LWAPP Header Pat Calhoun (pacalhou), May 5 2006
Results generated by Tiger Technologies using MHonArc.