Subject: [Capwap] Proposed Resolution to Issue 170 "Result code in Join Response is not sufficient" /was Re: A commentary on CAPWAP-01 operations

From: "Dorothy Stanley" <[email-masked]>
Date: Fri, 29 Sep 2006 14:33:45 -0700

All,

Issue 170 is listed below:
**
*22) Result code in Join Response is not sufficient, for instance WTP HW
not supported.

<PRC> Well, the protocol does not require this because the Discovery
Response would never be sent (as the protocol stands today).*

The proposed resolution to Issue 170 is:

If  Discover Request/Response messages are sent, then the current
Result codes are sufficient. But if the Discover Request/Response messages
are not sent - they are indicated as optional in the text, then the
commenter
is correct.

Insert the following result code value at the end of 4.4.28:

8  Failure (Join Failure, WTP Hardware not supported)

Comments welcome.

Thanks,

Dorothy

On 6/30/06, Michael Montemurro <[email-masked]> wrote:
>
> David, Pat,
>
> I created issues 150-198 to deal with the points in David's email. Happy
> hunting!
>
> Mike
>
>
>  On 6/27/06, Pat Calhoun (pacalhou) <[email-masked]> wrote:
> >
> > Going through David's lengthy document, he has raised an interesting
> > number of points that I believe require issues to be created. At one
> > point I'm paraphrasing Dave's comments in order to be brief, and
> > introducing my own numbering scheme.
> >
> > 1) Can message elements be in any order? (I believe they should be)
> >
> > <PRC> Yes, and I suspect we need to include text to make it more
> > obvious.
> >
> >
> > 2) Are all specified message elements required? (The obvious answer is
> > "yes", but this document doesn't discuss versioning. For example, what
> > if in a new version of CAPWAP an additional message element was to be
> > added. Would a new message type be created and the additional message
> > element added to it, or the existing type reused?)
> >
> > <PRC> This is a great question, and one that does need to be addressed
> > in the spec. In the Diameter protocol we dealt with this issue by
> > including a "Mandatory to implement" bit. If any AVP was received, whose
> > bit was set, yet was not recognized, then the request had to be
> > rejected.
> >
> > <PRC> We could consider something similar here, but I believe with the
> > firmware download component of the protocol it may be less of an issue -
> > although not guaranteed. I would hope (and expect) that as the CAPWAP
> > protocol extends, the AC would push new firmware to the WTP. This does
> > require that the initial part of the state machine be fairly static, and
> > this could be an area where the "Mandatory to implement" bit could be
> > useful as it would allow the AC to fall back to older protocol behavior.
> >
> >
> > 3) CAPWAP-01 doesn't do a good job of indicating which message elements
> > can be repeated.
> >
> > <PRC> Another good point. When we list the message elements, we should
> > note whether the frequently is 0-1 (meaning absent or once), 1 (only
> > once) or 0+ (meaning any number of them could be present.
> >
> >
> > 4) Can "additional" message elements be added to a message? (I believe
> > so for reporting capabilities, statistics, and     events. For
> > configuration, there is nothing in the protocol that says what happens
> > when one end gets an configuration     element it doesn't know about.
> > Should it be ignored, and the other elements processed, or should the
> > complete operation     failed?)
> >
> > <PRC> The "Mandatory to implement" bit above could address this issue.
> > If an unrecognized message element is found to have the bit set, then
> > the whole message needs to be rejected. If the bit is not set, the
> > message element may be safely ignored.
> >
> >
> > 5) The config has a concept of "default value" for each configuration
> > attribute. However, the default values are not clearly specified. This
> > needs to be resolved to be able to support "default values".
> >
> > <PRC> Another good point raised by David.
> >
> >
> > 6) the documentation of which "binding specific" message elements are to
> > be included with CAPWAP messages is not consistent, and is difficult to
> > follow.
> >
> > <PRC> Has this been addressed in the latest (-02) document?
> >
> >
> > 7) There are some message elements that cause "actions". This approach
> > to protocol design is problematic and should be eliminated.
> >
> > <PRC> Could you be more specific as well as provide guidance on what you
> > would like to see?
> >
> >
> > 8) The message types are inconsistently named, and do not follow the
> > conventions of well designed protocols. Can the operations be named
> > consistently with the following terminology:
> >   1) request/response (used to get/set/perform action)
> >   2) report/ack (use to tell the other side something)
> >
> > <PRC> Could you provide your thoughts on which messages fall within
> > which one of your categories?
> >
> >
> > 9) Many of the configuration items, and status items are not listed in
> > one section with definitions. (Well make it two sections - one for
> > CAPWAP and the other which is "binding" specific.) For example, not all
> > of the time period lengths are identified and specified in section 4.5.
> >
> > <PRC> Unfortunately, the document has gone back and forth a few times
> > and before we opt to change the structure of the document, I'd like to
> > ensure that we have broad agreement on what we want - with the
> > understanding that we will never make everyone happy.
> >
> >
> > 10) each operation should have listed in which states it can be sent and
> > received
> >
> > <PRC> I do not understand your comment.
> >
> >
> > 11) All strings, such as WTP location, should be changed from US-ASCII
> > encoding to UTF-8 encoding.
> >
> > <PRC> Agreed.
> >
> > 12) The term "mobile" is not really accurate when describing wireless
> > interfaces, since wireless does not imply      mobile. Can we just use
> > the techie term "STA" instead.
> >
> > <PRC> I agree we should use the term Station, or STA for short.
> >
> >
> > 13) The WTP Descriptor message element contains too much information,
> > lacks clarity on the WTP encryption field and includes version numbers,
> > which should be in string form.
> >
> > <PRC> To the first point, I disagree. I think there is value in knowing
> > everything about the WTP. The AC vendors can expose whatever information
> >
> > they want, but I don't believe anything is unnecessary.
> >
> > <PRC> To the second point, this is one of those areas where the concept
> > of the technology binding creates complexity. Given that we cannot
> > simply discuss 802.11i at this point, the only thing we can do is punt
> > to another section in the technology binding section. That said, I agree
> > with Dave that the 802.11 binding section is too light in this area.
> > However, I would much prefer that instead of trying to address this
> > specific issue, we discuss whether we should even be supporting the mode
> > of operation where 802.11i is performed in the AC - especially with the
> > introduction of DTLS to secure the data plane. Right now, it just feels
> > like we have too many options and I am worried that interoperability
> > will be severely impacted (not to mention protocol complexity).
> >
> > <PRC> To the last point, I have no issues with including text stating
> > that the version numbers should be in string form.
> >
> >
> > 14) The WTP Descriptor information is not required at Join time.
> >
> > <PRC> Well, as far as I can tell, I think there's value in knowing
> > whether the WTP can even be supported by the AC. So the more info is
> > provided by the WTP, the better the AC can determine whether it should
> > just ignore the WTP or not. This could be done because it knows that the
> > firmware running on the WTP is not compatible, and it has no new
> > firmware to download.
> >
> >
> > 15) Are the values in the WTP Frame Encryption a capabilities bit, or an
> > enum?
> >
> > <PRC> Looks like an enum to me. Not sure what Dave would prefer the text
> > to read. There are various other similar comments throughout, which I
> > will not repeat here.
> >
> >
> > 16) The Discovery Response is broken. The AC SHOULD NOT be providing any
> > info to a WTP (or something that claims to be a WTP). Also, the AC
> > should tell the WTP what to do next, with choices: 1) Ok to try to join,
> >
> > 2) don't try to join, 3) try                     discover on a list of
> > returned ACs)
> >
> > <PRC> I don't believe there is an issue with sending the AC's
> > information to the WTP, but would solicit input from the list. That
> > said, some of the information in the AC Descriptor is required, such as
> > the current load on the AC. No point is trying to join if he AC
> > indicates it's already at max capacity.
> > <PRC> I believe if the AC does not return the response, then it implies
> > (2). Otherwise, it is (1). (3) is handled during the join or configure
> > process, which I believe is right.
> >
> >
> > 17) Is AC Name text?
> >
> > <PRC> Yes, and same with WTP Name.
> >
> >
> > 18) Primary Discovery are not required.
> >
> > <PRC> Disagree. Required for failover.
> >
> >
> > 19) The text does not make it clear that the contents of the WTP
> > Location is informative only, and as Dave calls it, a "scratchpad".
> >
> > <PRC> Well, to be honest, I thought the example "next to the fridge"
> > made it clear that the information did not derive from any scientific
> > formula. The description also states this is a user-defined. I believe
> > this should be good enough.
> >
> >
> > 20) Session is not required
> >
> > <PRC> I believe you may be correct that with the transition to DTLS,
> > this is no longer required.
> >
> >
> > 21) need to send "common name" as found in the WTP CERT so that the AC
> > can verify
> >
> > <PRC> The protocol currently relies on the MAC address being the key
> > that binds the certificate to the WTP. I don't see a need to change
> > this.
> >
> >
> > 22) Result code in Join Response is not sufficient, for instance WTP HW
> > not supported.
> >
> > <PRC> Well, the protocol does not require this because the Discovery
> > Response would never be sent (as the protocol stands today).
> >
> >
> > 23) AC IPv4/IPv6 Addr discusses clustering, which is unnecessary.
> >
> > <PRC> Agreed.
> >
> >
> > 24) Change Echo to Keepalive or heartbeat.
> >
> > <PRC> I call it potato....
> >
> >
> > 25) What if all of the message elements do not fit within a single
> > CAPWAP control frame.
> >
> > <PRC> We should address this.
> >
> >
> > 26) AC Name with Index is all messed up...
> >
> > <PRC> Not really. You simply include more than one, and the index field
> > is clearly the priority. Don't understand the Multi-AC comment. No
> > inter-AC protocol implied here.
> >
> >
> > 27) WTP Board Data belongs in the Join, not configure.
> >
> > <PRC> Agreed, but wonder even more why we are duplicating this
> > information across both the WTP Descriptor and the WTP Board Data
> > message elements.
> >
> >
> > 28) The WTP Static IPv4 Address should not have the Static bit, but
> > instead state that 0.0.0.0 means a static address is not to be used.
> >
> > <PRC> I don't have an issue with this request, but in the end we have
> > the same function. The reason why I state this is that we can refine
> > this protocol until the cows come home, and at one point we need to draw
> > a line in the sand.
> >
> >
> > 29) WTP Reboot Statistics belongs in the Join, and the reasons listed
> > are not clear enough.
> >
> > <PRC> Doesn't really matter whether this is included in the
> > configuration or the join, but if the WG agrees to move it. We can
> > clarify some of the reasons, as long as it provides value.
> >
> >
> > 30) The IEEE 802.11 WTP Radio Configuration message element's BSSID
> > field should be an array.
> >
> > <PRC> Disagree.
> >
> >
> > 30) The IEEE 802.11 WTP Radio Configuration message element's Country
> > Code is not clear enough.
> >
> > <PRC> The text points to the actual MIB element in the 802.11-1999
> > standard, which very clearly defines the contents of the field. I don't
> > think there's value in replicating the format of this field in the
> > CAPWAP standard.
> >
> >
> > 31) There seems like an awful lot of additional configuration message
> > elements that need to be specified here!
> >
> > <PRC> Having built a protocol based on this, it's not clear to me what's
> >
> > missing. I think it would be useful if you provided concrete details on
> > what's missing.
> >
> >
> > 32) Configuration Status is just plain broken because any configuration
> > change operation may fail and there is no           response to the
> > configuration changes specified in this command.
> >
> > <PRC> There certainly is - I guess I don't understand the concern.
> >
> >
> > 33) Use of Change State Event should instead be Radio Admin State.
> >
> > <PRC> Perhaps the two are not described properly. The first is used by
> > the WTP to inform the AC that something has occurred with a radio. The
> > second is used by the AC to enable/disable a radio.
> >
> >
> > 34) Report Timer needs to be in section 4.5 or 11
> >
> > <PRC> ok
> >
> >
> > 35) Should Idle Timeout be per radio, or per WTP, and should the value
> > be defined in section 4.5 or 11.
> >
> > <PRC> Per WTP, and yes. I believe it is fine as it is.
> >
> >
> > 36) WTP Fallback isn't well defined, and should be removed.
> >
> > <PRC> Disagree. I believe it is necessary to create enough resiliency in
> > the protocol/service.
> >
> >
> > 37) How are the "Rate Set" and "Supported Rates" encoded.
> >
> > <PRC> This was fixed in the -02
> >
> >
> > 38) AC Timestamp doesn't belong in the configuration, but instead in the
> > join.
> >
> > <PRC> Not sure this really matters....
> >
> >
> > 39) Add MAC ACL Entry - this is so strange and is being managed like no
> > other configuration data.
> >
> > <PRC> I do not understand the comment
> >
> >
> > 40) Decryption Error Report Period is not defined in section 4.5 or 11
> >
> > <PRC> ok, and note that the information has been moved to the IEEE
> > 802.11 RSNA Error Report From Mobile
> >
> >
> > 41) Configuration Update Response. today, there are primarily two types
> > of configuration models. The first is when config is changed, it is only
> > changed in the volatile copy (the memory or running). An explicit
> > command is needed to save the config to nonvolatile storage. The second
> > model has config both running (volatile) and saved (nonvolatile) config
> > changed when a config change is made. And there might be a special
> > command to have a config change apply to only one. In this case, there
> > is no need for a "save config to nonvolatile" command. It is not clear
> > what is suppose to be supported here in CAPWAP, and how does CAPWAP
> > support devices with no or very limited nonvolatile storage for config!
> >
> > <PRC> CAPWAP does not support WTPs with no nonvolatile storage. The
> > protocol has the AC push configs to the WTP, which saves them at the
> > time they are received. I do not believe anything else is required.
> >
> >
> > 42) Configuration Update Response includes the Result Code message
> > element, which includes values that do not appear to be relevant for
> > this message, and there are plenty of other failure cases
> >
> > <PRC> ok, but note that we are sharing a common message element. Any
> > suggestions on how to address your issue?
> >
> >
> > 43) Change State Event Report. This seems a little silly to be sent in
> > the "configure" state. It seems only appropriate for the "run" state.
> > Some might argue that even in the "run" state it shouldn't be sent after
> > a "config update" request that changes the operational state. However,
> > in the "run" state, it may take a while to have the operational state
> > change to follow the admin state. Thus, I think it is OK in the "run"
> > state after config changes."
> >
> > <PRC> I believe this was addressed in -02.
> >
> >
> > 44) Clear Config Request. this operation has several problems, which
> > include:
> >    1) currently, the CAPWAP-01 spec says that this can only be done in
> > the "run" state. This is silly. It should also be possible in the
> > "configure" state.
> > <PRC> I wonder why the AC would even consider clearing the WTP's state
> > before it even knows how it is configured.
> >
> >    2) the value of "manufacturing defaults" is not defined, and a poor
> > term to use, since it implies that that each manufacturer can have
> > different values. If so, then the AC will have no knowledge of the
> > config on the WTP! The problem of "default config values" has already be
> >
> > mentioned above. After each config attribute has been defined with a
> > default value, then the proper term would be "CAPWAP config defaults".
> > <PRC> Yes, you've raised this point already, and I agree that it does
> > need to be addressed.
> >
> >    3) This operation is not defined to have a response. This is broken,
> > since any config change can fail. Also, it is not defined what happens
> > next. Does this cause the WTP to reboot an start a "clean discovery"?
> > <PRC> This was addressed in -02
> >
> >
> > 45) Image Data Request. Yes, there are actually three different "Image
> > Data Request" messages. Which one is determined          by which of the
> > three message elements is contained. This is completely silly! There
> > should be three separate operations! Additionally, how does the WTP know
> > which image to get? The AC should be making that decision.
> >
> > <PRC> I believe the WTP is the only device that knows what it's filename
> >
> > should be. Why would an AC vendor know about file naming conventions
> > used by the WTP vendors? I believe your other issues are discussed in
> > the next items.
> >
> >
> > 46) Image Data Response. this is silly. This operation can fail! There
> > needs to be message element that indicates the          result.
> >
> > <PRC> How so? This is only used to send firmware to the WTP. Not clear
> > what could fail... Reading the image from flash?
> >
> >
> > 47) Image Data Request. when starting over again at the WTP start state,
> >
> > the WTP shouldn't use the "normal" discovery process, but instead "fast
> > track" a connection back to the AC that just downloaded the image. With
> > a little more          work, we could probably figure out a way to reuse
> >
> > the old DTLS session.
> >
> > <PRC> To what gain? What is so expensive about the discovery, and what
> > happened if the AC was not longer reachable?
> >
> >
> > 48) opcode - if this is here, might as well also have a value that
> > indicates last block of the image file, instead of looking at the block
> > size.
> >
> > <PRC> But we're just changing for the sake of changing - the protocol
> > works as-is.
> >
> >
> > 49) since this operation does not have the block number as a parameter,
> > the WTP must determine the block number via the CAPWAP message header
> > sequence number.  NOTE: DTLS does not provide in-order delivery of
> > packets. Also, this requires the WTP to remember state. This message
> > element should be re-engineered to have the following subfields:
> > [edited]
> >
> > <PRC> The control header includes a sequence number, and while we can
> > change the current protocol to match your recommendations, the protocol
> > does work. If it ain't broken...
> >
> >
> > 50) Image Data Response. this is silly. This operation can fail!  For
> > example, the WTP can run out of space to store          the block, or
> > there could be a failure in writing the block to storage. (Or as "Image
> > Data Request"(9.1a) is presently specified, the checksum match could
> > fail.) There needs to be message element that indicates the result.)
> > Note: don't need a block number field, since request and responses are
> > paired.
> >
> > <PRC> We can include a result code
> >
> >
> > 51) Image Data Request. silly beyond belief
> >
> > <PRC> Beauty is in the eye of the beholder ;-). Seriously, the protocol
> > does work, so what exactly are you looking for?
> >
> >
> > 52) Image Data Response. This is silly. This operation can fail! There
> > needs to be message element that indicates the          result.
> >
> > <PRC> See above comment.
> >
> > 53) Reset Request. ...
> >
> > <PRC> The comment is irrelevant now that Clear Config has changed.
> >
> >
> > 54) Reset Response. this is silly. This operation can fail! There needs
> > to be message element that indicates the          result.
> >
> > <PRC> I sense a trend. I will stop including these messages from now on.
> >
> >
> > 55)Duplicate IPv4 Address. how often is this reported if the condition
> > remains?
> >
> > <PRC> Only required once, I think, but we may want to include some text
> > covering that.
> >
> >
> > 56) the list of events seems understated!
> >
> > <PRC> Text and conditions please
> >
> >
> > 57) Data Transfer Request. Nice to have - remove.
> >
> > <PRC> Disagree. Providing diagnostics capabilities is required.
> >
> >
> > 58) Mobile Config Request. the actual details of how this works on both
> > splitMAC and especially localMAC are not well specified. That is, only
> > the figures and text in sections 11.1.1 and 11.1.2 provide any clue as
> > to events that would cause an AC to send this message type. Also, there
> > are restrictions on combinations of parameters that can be included in
> > the message.
> >
> > <PRC> I wonder whether other folks agree that more details are required.
> >
> >
> > 59) it doesn't say if one message can be used to update more than one
> > STA. It should be able.
> >
> > <PRC> No, otherwise you end up with the problem of associating specific
> > message elements with a given mobile. One mobile per request.
> >
> >
> > 60) IEEE 802.11 Mobile. shouldn't the STA MAC address be included so
> > this message element can be matched with a (4.4.8)Add Mobile message
> > element?
> >
> > <PRC> I believe this is to your previous point, but the protocol assumes
> > one mobile per request.
> >
> >
> > 61) IEEE 802.11 Update Mobile QoS. s this for data traffic to the AC? If
> > so, then why is this an 802.11 message element
> >
> > <PRC> Intended to be a way to push policies to the WTP to prioritize
> > mobile traffic.
> >
> >
> > 62) IEEE 802.11 WLAN Config Request. why is a new message type that is
> > 802.11 specific needed to modify 802.11 WLANs? It seems like the
> > existing "(8.4)Configuration Update Request" message could be used.
> >
> > <PRC> To be more specific only.
> >
> >
> > 63) note here there are information elements to create, delete, and
> > modify WLANs. However, for message type "(10.1)Mobile Config Request",
> > there is only add and delete (and the "add" used to modify).
> >
> > <PRC> Correct. The protocol requires the AC to resend a new add with a
> > different policy. No specific reason, but if this is deemed
> > inconsistent, we could change it.
> >
> >
> > 64) IEEE 802.11 Assigned WTP BSSID. The mapping of WLAN IDs to BSSIDs
> > seems like it needs a little more work
> >
> > <PRC> What exactly would you like to see?
> >
> >
> > Pat Calhoun
> > CTO, Wireless Networking Business Unit
> > Cisco Systems
> >
> >
> >
> > > -----Original Message-----
> > > From: David T. Perkins [mailto:[email-masked]]
> > > Sent: Thursday, June 22, 2006 4:31 PM
> > > To: [email-masked]
> > > Subject: [Capwap] A commentary on CAPWAP-01 operations
> > >
> > > HI,
> > >
> > > I've attached a long file that summarizes the operations in
> > > CAPWAP-01.
> > >
> > > Enjoy,
> > > /david t. perkins
> > >
> > _________________________________________________________________
> > 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