Subject: [Capwap] Review of LWAPP 3.0

From: Michael Montemurro <[email-masked]>
Date: Mon, 23 Jan 2006 11:27:45 -0500

I have spent some time going through the latest LWAPP draft (v 3.0) and I
have a number of comments that I think should be resolved. Some of them, I
believe, have been discussed. I think we should add the others to the issues
list.

Thanks,

	Mike

Here they are:

Page 8, Figure 1. Figure 1 refers to the LWAPP architecture for split MAC.
Rename the figure to "Representative LWAPP Architecture for Split MAC".

Page 12, Figure 2. It's possible for the WTP to receiving a new image while
in the RUN state (i.e. image upgrade "out-of-band"). After the image
download is complete and has been verified, the WTP would reset. Would it be
worthwhile to include this case?

Page 12, Figure 2. If the WTP already knows which AC it wants to join with,
it should be possible to "Join" without doing "Discovery". It would speed up
system recovery. 

Page 21, Section 3.1. It would be nice to include a "session identifier" in
the transport header. A session identifier would make it easier to do a
lookup on the WTP.

Page 24, Section 3.3 and Section 6.1. If you have a bit set to identify a
control message, why do you need 2 UDP ports to differentiate between
control and data messages for the protocol?

Page 25, Section 3.3.2. You could use SLP for discovery. SLP describes both
a broadcast mechanism and a unicast mechanism for discovery.

Page 28, Section 4.2.1. The Session ID field is only included in the header
for Control packets. Why it is not included for all packets. It's easier to
do a table lookup using a Session ID versus MAC or other data field.

Page 29, Section 4.2.1.1. Would it make sense to label a range of message
types as "reserved" and/or "vendor specific".

Page 34, Section 5.1.3. The WTP should indicate whether it is capable of
operating in Local/Split MAC modes. Since the presence of the Integration
function on the WTP is the requirement for Local MAC, an additional field
called "Bridging Capability" should be added that would be 0 if the WTP
cannot bridge traffic locally (can only operate in split MAC mode); and 1 if
the WTP can bridge traffic and could operate in either split or local MAC
mode.

Page 34, Section 5.1.3. LWAPP seems to assume that WLAN radios will support
16 BSS's per Radio. It would be better not assume that every WTP supports 16
radios and add a field to indicate the number of virtual networks per radio.

Page 37, Section 5.2.4 (and Section 5.2.5). The first paragraph of this
section refers to "load". How is it defined? If it simply refers to the
number of WTP's, why call it load and simply refer to it as the WTP count.

Page 3, Section 5.3. Why define a separate message for Primary Discovery?
Why not simply add an option in the header of the primary discovery and
reduce the number of messages in the protocol?

Page 42, Section 6.1.4. How does the WTP know its location? Would this be a
GPS sort of thing for outdoors? I would think that for in-building, it would
be better for the AC to tell the WTP where it is. Moreover, we don't really
understand why the WTP needs to understand its location?

Page 43, Section 6.1.7. In order to maintain uniqueness, it would be better
for the AC to generate the session ID and transmit it to the WTP. It's
easier for the AC to maintain uniqueness.

Page 46, Section 6.2.2. The model for sending back status is good. The
definition of the error codes need to be clarified.

Page 52, Section 6.5. CTP has a similar mechanism for keep-alive. In the
case where the network between the AC and the WTP is un-reliable, it was
necessary to address the case where a keep-alive message was dropped. CTP
allows for a fixed number of echo messages to be lost before terminating the
session.

Page 66, Section 7.4.11. Why do you need to provide persistent and
non-persistent Blacklist entries? Does this have to do with the two options
for configuration?

Page 67, Section 7.5. Are there any status codes for Configuration Response?

Page 71, Section 8.3. This command could be combined with the Change State
event. We would assume that system state changes should be controlled by the
AC. That way the AC could reset the WTP to either the Join or Discovery
state.

Page 91, Section 11.1.2. CTP allows client data to be optionally tunneled to
the AC. Under certain network deployments, the policy would be applied at
the AC for Local MAC behavior.

Page 93, Section 11.1.2. Add a bullet worded as follows: "The WTP optionally
may tunnel client data frames to the AC.

Page 94, Section 11.3.1. It would be better to report RSSI and data rate,
instead of RSSI and SNR. This gives an indication of the interference as
well as channel capacity.

Page 95, Section 11.4. It would be better for the WTP to indicate the number
of virtual WLAN's it supports as part of the Discovery process (at the same
time that it gives its radio information).

Page 95, Section 11.5. Could this section be renamed to "Quality of Service
for Control Messages"?

Page 96, Section 11.7.1.1. Is the Session Key information in the Add Mobile
message intended to carry the PMK?

Page 96, Section 11.7.1.1. Why are Capabilities and Supported Rates included
in the Add Mobile message?

Page 96, Section 11.7.1.1. Is all of this information required for Add
Mobile in the local MAC case?

Page 99, Section 11.7.1.1. The "QoS" field provides an interesting mechanism
for doing STA-based prioritization. However strictly speaking, it does not
really need to be part of the protocol.

Page 99, Section 11.7.1.1. Is there any way to provision TSPEC's for the
STA? Or would they be done on the AC?

Page 99, Section 11.7.1.2. I don't understand what this message elementis
used for. There is already a Session Key entry on page 97. Furthermore, what
does "???" refer to? I assume this message would plumb PMK's.

Page 102, Section 11.7.2.1. The statistics element does not include counts
of management messages: Assoc, Auth, Dissassociate, Deauth, etc. We assume
that these message counts would be tracked by the AC. Is that correct? How
would this work in a local MAC case? What about traffic count information in
a local MAC case?

Page 104, Section 11.8.1. The description for Config-Request describes a
message sent from the AC to the WTP. In Section 7.2, the config request is
sent from the AP to the WTP. I would prefer the mechanism described in
11.8.1.
40.	

Page 105, Section 11.8.1.1. I would like to add an additional element called
something like "tunnel client traffic" to provision a Local MAC WTP to
tunnel client data back to the AC.

Page 106, Section 11.8.1.1. Practically speaking, it would be very difficult
to maintain a scheduler with different WMM queue properties on the same
radio. Would it be possible to configure WMM queues along with the radio
properties and simply provide an enabled/disabled configuration here?

Page 107, Section 11.8.1.1. The "Broadcast SSID" term is confusing. It
should be renamed to a more common term such as "suppress SSID".

Page 108, Section 11.8.1.1. I would like to suggest a slightly different
behavior for configuring a WLAN on a WTP. The AC would send a WLAN ID as
part of the Configuration Request and the WTP would respond with the BSSID
that would be used for the WLAN as part of the Configuration Response. In
that way, the WTP is responsible for maintaining BSSID to WLAN ID mappings.

Page 111, Section 11.9.1. I recommend that the WMM IE goes here. Its really
a radio property given that all WMM-enabled traffic would need to use the
same parameters.

Page 112, Section 11.9.1. If the WTP is responsible for maintaining WLAN ID
to BSSID mappings (see comment 39), then the AC does not have to know the
WLAN ID to BSSID mappings.

Page 121, Section 11.9. Page 124. There were a couple of configuration
elements missed: short/long preamble, 802.11g protection mode, 802.11g mode:
PBCC, OFDM-DSSS. Actually, it would be a good exercise to go through the
current 802.11 MIB and make sure that nothing was missed as part of the
binding.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 24 Jan 2006 16:40:23 -0800

> Rename the figure to "Representative LWAPP Architecture for 
Issue 47, resolved.

> 
> Page 12, Figure 2. It's possible for the WTP to receiving a 
> new image while in the RUN state (i.e. image upgrade 
> "out-of-band"). After the image download is complete and has 
> been verified, the WTP would reset. Would it be worthwhile to 
> include this case?
This is an issue that was raised by the eval team, and has already
been resolved.

> 
> Page 12, Figure 2. If the WTP already knows which AC it wants 
> to join with, it should be possible to "Join" without doing 
> "Discovery". It would speed up system recovery. 
There is nothing in the Discovery that is cached so it is possible,
but I would not necessarily recommend that we make any changes to
the state machine as the Discovery phase does provide a way for
the WTP to decide the best AC to connect to. I feel the benefits would
be small vs. the complexity in the spec.

> 
> Page 21, Section 3.1. It would be nice to include a "session 
> identifier" in the transport header. A session identifier 
> would make it easier to do a lookup on the WTP.
There is a session identifier in the control header, and it is used to
identify the encryption key. However, there is no session identifier
for user data because:
1. In some cases, there is no session (e.g., probe, broadcast)
2. The session is identified via the destination MAC address
3. Any encryption would use the identifiers defined in 802.11i anyways

> Page 24, Section 3.3 and Section 6.1. If you have a bit set 
> to identify a control message, why do you need 2 UDP ports to 
> differentiate between control and data messages for the protocol?
Issue 48 created, and this issue is resolved in the next draft.

> 
> Page 25, Section 3.3.2. You could use SLP for discovery. SLP 
> describes both a broadcast mechanism and a unicast mechanism 
> for discovery.
Could you please send proposed text?

> 
> Page 28, Section 4.2.1. The Session ID field is only included 
> in the header for Control packets. Why it is not included for 
> all packets. It's easier to do a table lookup using a Session 
> ID versus MAC or other data field.
Replicate from above. Rejected for same reason.

> 
> Page 29, Section 4.2.1.1. Would it make sense to label a 
> range of message types as "reserved" and/or "vendor specific".
There is already a change request to allow for vendor specific control
messages. I would prefer that we address this request through the same
tracker request 37 (but added your comment to this tracker entry).

> 
> Page 34, Section 5.1.3. The WTP should indicate whether it is 
> capable of operating in Local/Split MAC modes. Since the 
> presence of the Integration function on the WTP is the 
> requirement for Local MAC, an additional field called 
> "Bridging Capability" should be added that would be 0 if the 
> WTP cannot bridge traffic locally (can only operate in split 
> MAC mode); and 1 if the WTP can bridge traffic and could 
> operate in either split or local MAC mode.
This is an existing request (tracker entry 3), which I have sent
text to the mailing list about. I would appreciate if you could
provide your comments on the submitted text on whether it addresses
your comment.

> 16 BSS's per Radio. It would be better not assume that every 
> WTP supports 16 radios and add a field to indicate the number 
> of virtual networks per radio.
At one point, the sheer number of beacons will saturate the air waves,
so we need to pick a maximum. What number do we want? Frankly, 16 seems
like a lot given that we need to transmit a packet every 100ms per
BSS.

Created Issue 50.

> 
> Page 37, Section 5.2.4 (and Section 5.2.5). The first 
> paragraph of this section refers to "load". How is it 
> defined? If it simply refers to the number of WTP's, why call 
> it load and simply refer to it as the WTP count.
Tracker entry 12 handles this one, and has already been resolved.

> Why not simply add an option in the header of the primary 
> discovery and reduce the number of messages in the protocol?
The idea is for the primary AC to know why it is receiving a Discovery
message, and this is separate from a normal discovery mode. If the AC
wants to allocate resources for WTPs for which it is primary, then
it can do so through this message.

> 
> Page 42, Section 6.1.4. How does the WTP know its location? 
> Would this be a GPS sort of thing for outdoors? I would think 
> that for in-building, it would be better for the AC to tell 
> the WTP where it is. Moreover, we don't really understand why 
> the WTP needs to understand its location?
Added tracker entry 51 and resolved by adding the following text
"This information is configurable by the network
 administrator, and allows for the WTP's location to be determined
 through the field."

> 
> Page 43, Section 6.1.7. In order to maintain uniqueness, it 
> would be better for the AC to generate the session ID and 
> transmit it to the WTP. It's easier for the AC to maintain uniqueness.
The text does not state that global uniqueness is required, so I
am not sure why you think this would help.

> 
> Page 46, Section 6.2.2. The model for sending back status is 
> good. The definition of the error codes need to be clarified.
I suspect you may have the order of the sections inversed because
6.2.2 is the Status, not the Result Code. Could you clarify
your point?

> 
> Page 52, Section 6.5. CTP has a similar mechanism for 
> keep-alive. In the case where the network between the AC and 
> the WTP is un-reliable, it was necessary to address the case 
> where a keep-alive message was dropped. CTP allows for a 
> fixed number of echo messages to be lost before terminating 
> the session.
Correct, and this is addressed in section 6.6 (Echo Response).

> 
> Page 66, Section 7.4.11. Why do you need to provide 
> persistent and non-persistent Blacklist entries? Does this 
> have to do with the two options for configuration?
Local and Split MAC. For Local MAC, you need to have some way to
permanently store the blacklist entries because you will need
this list to be used even across reboots.

> Page 67, Section 7.5. Are there any status codes for 
It simply uses the same values defined in the original Status Code
Section.

> 
> Page 71, Section 8.3. This command could be combined with the 
> Change State event. We would assume that system state changes 
> should be controlled by the AC. That way the AC could reset 
> the WTP to either the Join or Discovery state.
One disables a radio, while the other resets the AP. These are 
mutually exclusive, IMHO.

> 
> Page 91, Section 11.1.2. CTP allows client data to be 
> optionally tunneled to the AC. Under certain network 
> deployments, the policy would be applied at the AC for Local 
> MAC behavior.
This is already in tracker entry 3, and existing text has been submitted
on the list.

> 
> 
> Page 93, Section 11.1.2. Add a bullet worded as follows: "The 
> WTP optionally may tunnel client data frames to the AC.
Tracker entry 52 created, and the issue is resolved by changing the
existing
text to:
   o  The WTP optionally may tunnel client data frames to the AC.  If
      client data frames are locally bridged, the WTP will need to
      provide the necessary encryption and decryption services.

> 
> Page 94, Section 11.3.1. It would be better to report RSSI 
> and data rate, instead of RSSI and SNR. This gives an 
> indication of the interference as well as channel capacity.
I would argue that we probably need all three, but I've created tracker
entry 53 for this

> 
> Page 95, Section 11.4. It would be better for the WTP to 
> indicate the number of virtual WLAN's it supports as part of 
> the Discovery process (at the same time that it gives its 
> radio information).
Duplicate issue from above, using Tracker 50.

> 
> Page 95, Section 11.5. Could this section be renamed to 
> "Quality of Service for Control Messages"?
Tracker entry 54 created, and resolved.

> 
> Page 96, Section 11.7.1.1. Is the Session Key information in 
> the Add Mobile message intended to carry the PMK?
Added tracker entry 55, and added the following text:
"For dynamically created keys, this is commonly known
 as a Pairwise Transient Key (PTK)."

> 
> Page 96, Section 11.7.1.1. Why are Capabilities and Supported 
> Rates included in the Add Mobile message?
Because they are negotiated on a per user basis. The WTP
advertises in the beacon and probe, but the station will send
its rates (and capabilities) in the association request, so this
allows the AC to send what it had received to the WTP.

> 
> Page 96, Section 11.7.1.1. Is all of this information 
> required for Add Mobile in the local MAC case?
Issue 63 created.

> 
> Page 99, Section 11.7.1.1. The "QoS" field provides an 
> interesting mechanism for doing STA-based prioritization. 
> However strictly speaking, it does not really need to be part 
> of the protocol.
Correct, and I have cleaned that up. Issue 56.

> 
> Page 99, Section 11.7.1.1. Is there any way to provision 
> TSPEC's for the STA? Or would they be done on the AC?
Issue 64 created.

The TSPEC is processed on the WTP because with TGw (Management Frame
Protection), the packet will be encrypted between the AC and the STA
when AC encryption is enabled. This means that TCLASS policing and
classification MUST be done in the AC, and therefore the AC MUST add
the proper QoS fields (incl. UP field), and add the appropriate DSCP or
Dot1P field. Note that there is already a way to communicate the desire
to use either DSCP or Dot1P to the WTP in LWAPP.

The major issue, which we've raised before, is that the WTP has no way
to enforce the UP to TCLASS mapping on the upstream packets, and
therefore
it is very easy for a client to blow its reservation, which only the
AC could catch.

> 
> Page 99, Section 11.7.1.2. I don't understand what this 
> message elementis used for. There is already a Session Key 
> entry on page 97. Furthermore, what does "???" refer to? I 
> assume this message would plumb PMK's.
Tracker entry 57, and the original intention was to split up the
key from the original message element. In the new draft this 
split is complete, and therefore this ambiguity no longer
exists.

> 
> Page 102, Section 11.7.2.1. The statistics element does not 
> include counts of management messages: Assoc, Auth, 
> Dissassociate, Deauth, etc. We assume that these message 
> counts would be tracked by the AC. Is that correct? How would 
> this work in a local MAC case? What about traffic count 
> information in a local MAC case?
Even in the local MAC case, these messages are forwarded to the AC,
so it can maintain statistics regardless.

> 
> Page 104, Section 11.8.1. The description for Config-Request 
> describes a message sent from the AC to the WTP. In Section 
> 7.2, the config request is sent from the AP to the WTP. I 
> would prefer the mechanism described in 11.8.1.
> 40.	

There are two types of configuration messages, one that comes from
the WTP to the AC, and is used for the WTP to update the AC with its
config at boot time. The second allows the AC to push down a new
config to the WTP, and this can occur at run time. The former is
called the Configure Request, while the latter is called the
Configuration
update Request. That said, I think we should come up with a different
set of names to differentiate them better.

Issue 58

> 
> Page 105, Section 11.8.1.1. I would like to add an additional 
> element called something like "tunnel client traffic" to 
> provision a Local MAC WTP to tunnel client data back to the AC.
Issue 59.

> 
> Page 106, Section 11.8.1.1. Practically speaking, it would be 
> very difficult to maintain a scheduler with different WMM 
> queue properties on the same radio. Would it be possible to 
> configure WMM queues along with the radio properties and 
> simply provide an enabled/disabled configuration here?
I disagree. I believe that this provides the flexibility for
people to create their MACs to support such a differentiation.

> 
> Page 107, Section 11.8.1.1. The "Broadcast SSID" term is 
> confusing. It should be renamed to a more common term such as 
> "suppress SSID".
Tracker 60 and resolved in next draft.

> 
> Page 108, Section 11.8.1.1. I would like to suggest a 
> slightly different behavior for configuring a WLAN on a WTP. 
> The AC would send a WLAN ID as part of the Configuration 
> Request and the WTP would respond with the BSSID that would 
> be used for the WLAN as part of the Configuration Response. 
> In that way, the WTP is responsible for maintaining BSSID to 
> WLAN ID mappings.
This would complicate how the broadcast/multicast mapping works,
so I'd like to better understand how you would propose to resolve
this issue.

Issue 65 created.

> 
> Page 111, Section 11.9.1. I recommend that the WMM IE goes 
> here. Its really a radio property given that all WMM-enabled 
> traffic would need to use the same parameters.
See my above response

> 
> Page 112, Section 11.9.1. If the WTP is responsible for 
> maintaining WLAN ID to BSSID mappings (see comment 39), then 
> the AC does not have to know the WLAN ID to BSSID mappings.
Which creates additional issues in terms of broadcast mapping because
the AC does need this info. Added entry 61

> 
> Page 121, Section 11.9. Page 124. There were a couple of 
> configuration elements missed: short/long preamble, 802.11g 
> protection mode, 802.11g mode:
> PBCC, OFDM-DSSS. Actually, it would be a good exercise to go 
> through the current 802.11 MIB and make sure that nothing was 
> missed as part of the binding.

Added Tracker 62, and I will look into this one.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

---

From: sujay <[email-masked]>
Date: Fri, 27 Jan 2006 12:30:40 +0530

> 
> <snipped>
> 
> > Page 24, Section 3.3 and Section 6.1. If you have a bit set to
> > identify a control message, why do you need 2 UDP ports to 
 IMO;
 
 Agree,the bit set is deprecated if Layer 3 transport is ONLY used.
 
 My recommendation would be;
 For layer 3 transport as well, the data and control
 channels should be Distinguished with sockets and not Bits.
 
 Because;
 1. the data flow packet rate may need to be handled
 seperately from the control channel flow, as there rates will differ.
 -> so typically I would handle the data socket at a lower layer rather
 than the control traffic.
 -> it could also help in a distributed AC architecture, where the
 forwarding
 plane is separate from the control plane.
 
 2. considering multi threaded OS apps, implementations
 MAY find it better to use the efficient native threads 
 (rather than implement something of their own or re-invent).
 
 Regards,
 Sujay

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 27 Jan 2006 08:21:20 -0800

I believe Sujay is arguing for the use of separate UDP ports vs. the
'C' bit in the header. Please note that the 'C' bit was required for
non Layer 3. However, if we are opting to only support layer 3, then 
I would agree that the use of UDP ports is a great way to differentiate
control vs. data.

Thoughts?

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: sujay [mailto:[email-masked]] 
> Sent: Thursday, January 26, 2006 11:01 PM
> To: [email-masked]
> Subject: Re: [Capwap] Review of LWAPP 3.0
> 
> 
> > 
> > <snipped>
> > 
>  -> so typically I would handle the data socket at a lower 
> layer rather  than the control traffic.
>  -> it could also help in a distributed AC architecture, 
> where the  forwarding  plane is separate from the control plane.
>  
>  2. considering multi threaded OS apps, implementations  MAY 
> find it better to use the efficient native threads  (rather 
> than implement something of their own or re-invent).
>  
>  Regards,
>  Sujay
>  
>