Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jan 2006 13:55:32 -0800

Addressing the next round of comments.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, December 30, 2005 9:03 PM
> To: [email-masked]
> Subject: [Capwap] Comments on Draft 3 -- LWAPP
> 
> 
> I was re-reading the specification on the airplane and found 
> the following items that may need addressing.  I do not have 
> access to my previous e-mail so I may have duplicate comments 
> from before.
> 
> regards,
> 
> Philip
> 
> 
> Page 15 Join to Join Confirm
> WTP -- the Join Response must include a valid <== valid is mis-spelled
Done

> 
> Page 16:  Image Data to Image Data
> WTP:  Response that indicates that the AC has more data to send
> 
> I did not see in the definition of the Image Data how the WTP 
> knows there is more data to come from the AC.

The Image Data message element specifies:

    The Image Data field contains 1024 characters, unless the payload 
    being sent is the last one (end of file)

This means that a packet whose field does not include 1024 characters is
the last one. However, if the last packet is of length 1024, a clause is

required that specifies that a zero length payload needs to be
transmitted.

> 
> Page 18:  4th item -- This is the AC's normal state of operation, ...
> delete the phrasethat says [, and there are many events that 
> cause this to occur.]
Ok

> 
> Page 26 last paragraph
> In the event the WTP and AC are separated by a NAT, delete 
> the remark in between the comma's with the WTP using private 
> IP address space,
I agree

> 
> It is always the responsibility of NAT to manage the connection
> 
> Page 27:  LWAPP Packet Definitions
> 
> is the 802.11 FCS included in the LWAPP packets or not.  If 
> so, how does one know that this is occuring.

Yes, I caught this during the fixups. So I have cleaned up the "LWAPP
Data Messages" section to include:
4.1.  LWAPP Data Messages

   An LWAPP data message is a forwarded wireless frame.  When forwarding
   wireless frames, the sender simply encapsulates the wireless frame in
   an LWAPP data packet, using the appropriate transport rules defined
   in section Section 3.

   In the event that the encapsulated frame would exceed the transport
   layer's MTU, the sender is responsible for the fragmentation of the
   frame, as specified in the transport specific section of Section 3.

   The actual format of the encapsulated LWAPP data frame is subject to
   the rules defined under the specific wireless technology binding.  As
   a consequence, each wireless technology binding MUST define a section
   entitled "Payload encapsulation", which defines the format of the
   wireless payload that is encapsulated within the LWAPP Data messages.

Then I created the IEEE 802.11 binding section text:

11.3.1.  Payload encapsulation

   The LWAPP protocol defines the data frame, which allows a wireless
   payload to be encapsulated.  For IEEE 802.11, the 802.11 header and
   payload is encapsulated.  However, it is important to note that the
   802.11 FCS checksum is handled by the WTP.  This allows the WTP to
   validate a frame prior to sending it to the AC.  Similarly, when an
   AC wishes to transmit a frame towards a station, the WTP computes and
   adds the FCS checksum.

> 
> Page 59:  7.2.6 WTP Static IP Address Information
> 
> add note to say that IP Address/ Netmask/ Gateway are only 
> valid if static is 1 == or rearrange structure so that static 
> is first element and other elements follow if static is 1.

Fixed

> 
> Page 90:  2nd sentence should read:  The probe request is then sent
Done

> 
> Page 95:
> WLAN ID bit mask -- define which bit maps to which BSSID in 
> reading the ieee spec the bits start of the left but I think 
> here bit 0 is on the right.
Sorry, I don't follow

> 
> Page 97:  Supported Rates
> I think this IE is between 1 and 8 octets -- if the length of 
> the IE is not passed than the VLAN Name's starting position 
> cannot be known.
Changed the data structure to:

[...]
     | 802.11e Mode  |      Qos      |Length of Rates|Supported Rates|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Supported Rates                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Supported Rates|  VLAN Name...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Page 99:  VLAN Name --  do not understand "with local MAC WTPs"
Changed text to:
         An optional variable string containing the VLAN Name on which
the
	   WTP is to locally bridge user data. Note this field is only
valid
	   with WTPs configured in Local MAC mode.
> 
> Page 101:  VLAN Identifier:  PRC  ==  What is a PRC ?
A PRC is an editor who forgets to remove his initials from the draft.
The new
Text reads:
         The VLAN to assign to the mobile station being updated. Note
that this
         field is only valid if per station VLAN assignment is being
enforced
         on the WTP.

> 
> Page 113:  Add note on Number of BSSID's :  range 1 to 16

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

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

---

From: Philip Rakity <[email-masked]>
Date: Wed, 18 Jan 2006 14:53:20 -0800

Thanks -- My WLAN ID comment  is probably clearer.  I hope.

                0                   1
                  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 |          WLAN ID(s)           |
                 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

What is bit 0 == indicating the base bssid ?  I think it the field  
labeled 15 and the field labeled 00 is the 16th entry (counting from  
one).

Philip

>      | 802.11e Mode  |      Qos      |Length of Rates|Supported Rates|

Philip Rakity
[email-masked]

This message is hereby marked U4EA CONFIDENTIAL, is intended only for  
the use of the individual or individuals to which it is addressed and  
shall notbe disclose or made available to any other party except with  
the prior written consent of the sender. If the reader of this  
message is not the intended recipient, you are hereby notified that  
any dissemination, distribution or copying of this message is  
strictly prohibited. If you have received this communication in  
error, please notify us immediately by replying to the sender of this  
E-Mail.