Subject: [Capwap] Proposed Resolution to Issue 163 "WTP Descriptor information is not required at Join time" /was Re: A commentary on CAPWAP-01 operations

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

All,

Issue 163 "WTP Descriptor information is not required at Join time"  is
listed below:

*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.*
**
The proposed resolution to Issue 163 is:

Close with no change to the draft. The WTP descriptor element is included
in the optional Discover Request message and the Join Request to
indicate the WTP info to the AC. If the Discover Request is not sent, then
the Join Request is the first message in which the AC receives this
information.

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