idnits 2.17.1 draft-narasimhan-ietf-slapp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3389. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 80 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 209 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 462 has weird spacing: '... major versi...' == Line 3254 has weird spacing: '... in the recei...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: Future versions of SLAPP MAY NOT mandate support for earlier major versions of SLAPP so an implementation MUST NOT assume that a peer that supports version "n" will therefore support version "n - i" (where both "n" and "i" are non-zero integers and "n" is greater than "i"). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Valid control types -------------------0 - RESERVED (MUST not be used) 1 - Image Download Control Protocol 2 - 802.11 SLAPP control protocol 3-255 - RESERVED (to IANA) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If a regulatory domain is provisioned in the WTP, then the WTP indicates this by including this element in the capabilities list. If this information is not available at the WTP, then this element SHOULD not be included in the capabilities list. The process by which this information is provisioned into the WTP is beyond the scope of this document. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2005) is 6902 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'TBD' on line 841 == Unused Reference: '6' is defined on line 3320, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3990 (ref. '3') == Outdated reference: A later version (-04) exists of draft-ietf-capwap-objectives-00 ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-objectives (ref. '6') == Outdated reference: A later version (-05) exists of draft-rescorla-dtls-03 ** Downref: Normative reference to an Historic draft: draft-rescorla-dtls (ref. '7') ** Obsolete normative reference: RFC 2246 (ref. '8') (Obsoleted by RFC 4346) -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-03) exists of draft-krishna-slrrp-01 -- Possible downref: Normative reference to a draft: ref. '10' Summary: 12 errors (**), 0 flaws (~~), 12 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAPWAP Working Group P. Narasimhan 2 Internet-Draft Aruba Networks 3 Expires: December 2, 2005 D. Harkins 4 Trapeze Networks 5 S. Ponnuswamy 6 Aruba Networks 7 May 31, 2005 9 SLAPP : Secure Light Access Point Protocol 10 draft-narasimhan-ietf-slapp-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 2, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 The CAPWAP problem statement [3] describes a problem that needs to be 44 addressed before a wireless LAN (WLAN) network designer can construct 45 a solution composed of Wireless Termination Points (WTP) and Access 46 Controllers (AC) from multiple, different vendors. One of the 47 primary goals is to find a solution that solves the interoperability 48 between the two classes of devices (WTPs and ACs) which then enables 49 an AC from one vendor to control and manage a WTP from another. 51 The interoperability problem is more general than as stated in the 52 CAPWAP problem statement [3] because it can arise out of other 53 networks that do not necessarily involve WLAN or any wireless 54 devices. A similar problem exists in any network that is composed of 55 network elements that are managed by a centralized controller where 56 these two classes of devices are from different vendors and need to 57 interoperate with each other such that the network elements can be 58 controlled and managed by the controller. 60 A possible solution to this problem is to split it into two parts - 61 one that is technology or application independent which serves as a 62 common framework across multiple underlying technologies, and another 63 that is dependent on the underlying technology that is being used in 64 the network. For example, methods and parameters used by an 802.11 65 AC to configure and manage a network of 802.11 WTPs are expected to 66 be quite different than that used by an equivalent 802.16 controller 67 to manage a network of 802.16 base stations. The architectural 68 choices for these two underlying technologies may also be 69 significantly different. 71 In this draft, we present a protocol that forms the common 72 technology-independent framework and the ability to negotiate and 73 add, on top of this framework, a control protocol that contains a 74 technology-dependent component to arrive at a complete solution. We 75 have also presented two such control protocols - an 802.11 Control 76 protocol, and another a more generic image download protocol, in this 77 draft. 79 Even though the text in this draft is written to specifically address 80 the problem stated in [3], the solution can be applied to any problem 81 that has a controller (equivalent to the AC) managing one or more 82 network elements (equivalent to the WTP). 84 Table of Contents 86 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 87 1.1 Conventions used in this document . . . . . . . . . . . . 4 88 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 89 3. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.1 Protocol Description . . . . . . . . . . . . . . . . . . . 11 92 4.1.1 State Machine Explanation . . . . . . . . . . . . . . 11 93 4.2 Format of a SLAPP Header . . . . . . . . . . . . . . . . . 13 94 4.3 Version . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.4 Retransmission . . . . . . . . . . . . . . . . . . . . . . 14 96 4.5 Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 97 4.5.1 SLAPP Discover Request . . . . . . . . . . . . . . . . 15 98 4.5.2 SLAPP Discover Response . . . . . . . . . . . . . . . 18 99 4.6 SLAPP Discovery Process . . . . . . . . . . . . . . . . . 19 100 4.6.1 WTP . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 4.6.2 AC . . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 5. Security Association . . . . . . . . . . . . . . . . . . . . . 23 103 5.1 Example Authentication Models (Informative) . . . . . . . 23 104 5.1.1 Mutual Authentication . . . . . . . . . . . . . . . . 24 105 5.1.2 WTP-only Authentication . . . . . . . . . . . . . . . 24 106 5.1.3 Anonymous Authentication . . . . . . . . . . . . . . . 24 107 6. SLAPP Control Protocols . . . . . . . . . . . . . . . . . . . 25 108 6.1 802.11 Control Protocol for SLAPP . . . . . . . . . . . . 25 109 6.1.1 Suppported CAPWAP Architectures . . . . . . . . . . . 25 110 6.1.2 Transport . . . . . . . . . . . . . . . . . . . . . . 28 111 6.1.3 Provisioning and Configuration of WTP . . . . . . . . 29 112 6.1.4 Protocol Operation . . . . . . . . . . . . . . . . . . 64 113 6.2 Image Download Protocol . . . . . . . . . . . . . . . . . 69 114 6.2.1 Image Download Packet . . . . . . . . . . . . . . . . 70 115 6.2.2 Image Download Request . . . . . . . . . . . . . . . . 70 116 6.2.3 Image Download Process . . . . . . . . . . . . . . . . 71 117 6.2.4 Image Download State Machine . . . . . . . . . . . . . 72 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 77 119 8. Extensibility to other technologies . . . . . . . . . . . . . 78 120 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 79 122 Intellectual Property and Copyright Statements . . . . . . . . 80 124 1. Definitions 126 1.1 Conventions used in this document 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 130 document are to be interpreted as described in RFC 2119 [1]. 132 2. Introduction 134 The need for a protocol by which wireless LAN (WLAN) Access 135 Controllers (AC) can control and manage Wireless Termination Points 136 (WTP) from a different vendor has been presented in the CAPWAP 137 problem statement [3]. We believe that this problem is more general 138 than as stated in [3] and can be found in any application, including 139 non-wireless ones, that requires a central controller to control and 140 manage one or more network elements from a different vendor. 142 One way to solve the CAPWAP problem is to define a complete control 143 protocol that enables an AC from one vendor to control and manage a 144 WTP from a different vendor. But a solution that is primarily 145 focused towards solving the problem for one particular underlying 146 technology (IEEE 802.11, in this case) may find it difficult to 147 address other underlying technologies. Different underlying 148 technologies may differ on the set of configurable options, and 149 different architectural choices that are specific to that underlying 150 technology (similar to the local MAC vs. split MAC architectures in 151 802.11). The architectural choices that are good for one underlying 152 technology may not necessarily work for another. Not to forget that 153 there may be multiple architectural choices [2] even for the same 154 underlying technology. A monolithic control protocol that strives to 155 solve this problem for multiple technologies runs the risk of adding 156 too much complexity and not realizing the desired goals, or it runs 157 the risk of being too rigid and hampering technological innovation. 159 A different way to solve this problem is to split the solution space 160 into two components - one that is technology agnostic or independent, 161 and another that is specific to the underlying technology or even 162 different approaches for the same underlying technology. The 163 technology-independent component would be a common framework that 164 would be an important component of the solution to this class of 165 problems without any dependency on the underlying technology (i.e. 166 802.11, 802.16, etc.) being used. The technology-specific component 167 would be a control protocol that would be negotiated using this 168 common framework and can be easily defined to be relevant to that 169 technology without the need for having any dependency on other 170 underlying technologies. This approach also lends itself easily to 171 extend the solution as new technologies arise or as new innovative 172 methods to solve the same problem for an existing technology present 173 themselves later in the future. 175 In this draft, we present secure light access point protocol (SLAPP), 176 a technology-independent protocol by which network elements that are 177 meant to be centrally managed by a controller can discover one or 178 more controllers, perform a security association with one of them, 179 and negotiate a control protocol that they would use to perform the 180 technology-specific components of the control and provisioning 181 protocol. We have also presented two control protocols in this draft 182 - an 802.11 control protocol for provisioning and managing a set of 183 802.11 WTPs, and an image download protocol that is very generic and 184 can be applied to any underlying technology. 186 Figure 1 shows the model by which a technology-specific control 187 protocol can be negotiated using SLAPP to complete a solution for a 188 certain underlying technology. The figure shows a control protocol 189 each for 802.11 and 802.16 technology components, but the SLAPP model 190 does not preclude multiple control protocols within a certain 191 technology segment. For example, a certain technology-specific 192 control protocol may choose to support only the local MAC 193 architecture [2] while deciding not to support the split MAC 194 architecture [2]. While the image download protocol is presented in 195 this draft, a SLAPP implementation MUST NOT assume that this control 196 protocol is supported by other SLAPP implementations. 198 Negotiated 199 SLAPP Control 200 Protocol 202 +-------------------------+ +------------+ 203 | | | | 204 | SLAPP | | Image | 205 | (technology-independent +-------+----->| Download | 206 | framework) | | | protocol | 207 | | | | | 208 | negotiate one control | | +------------+ 209 | protocol here | | 210 +-------------------------+ | 211 | +------------+ 212 | | | 213 | | 802.11 | 214 +----->| control | 215 | | protocol | 216 | | | 217 | +------------+ 218 | 219 | 220 | +------------+ 221 | | | 222 | | 802.16 | 223 +----->| control | 224 | | protocol | 225 | | | 226 | +------------+ 227 | 228 | ....... 230 Figure 1: SLAPP Protocol Model 232 The control protocols that are negotiable using SLAPP are expected to 233 be published ones that have gone through a review process in 234 standards bodies such as the IETF. The control protocols can either 235 re-use the security association created during SLAPP or have the 236 option of clearing all SLAPP state and restarting with whatever 237 mechanisms are defined in the control protocol. 239 Recently, there was a significant amount of interest in a similar 240 problem in the RFID space that has led to the definition of a simple 241 lightweight RFID reader protocol (SLRRP) [10]. It is quite possible 242 that SLRRP could be a technology-specific (RFID, in this case) 243 control protocol negoriated during a common technology-independent 244 framework. 246 All of the text in the draft would seem to be written with a WLAN 247 problem in mind. Please note that while the letter of the draft does 248 position the solution to solve a CAPWAP-specific problem, the spirit 249 of the draft is to address the more general problem. 251 3. Topology 253 The SLAPP protocol supports multiple topologies for interconnecting 254 WTPs and ACs as indicated in Figure 2. 256 In Figure 2, we have captured four different interconnection 257 topologies. 259 1. The WTP is directly connected to the AC without any intermediate 260 nodes. Many WTPs are deployed in the plenum of buildings and are 261 required to be powered over the Ethernet cable that is connecting 262 it to the network. Many ACs in the marketplace can supply power 263 over etherent and in the case where the AC is the one powering 264 the WTP, the WTP is directly connected to the AC. 266 2. The WTP is not directly connected to the AC, but both the AC and 267 the WTP are in the same L2 (broadcast) domain. 269 3. The WTP is not directly connected to the AC, and they are not 270 present in the same L2 (broadcast) domain. They are on two 271 different broadcast domains and have a node on the path that 272 routes between two or more subnets. 274 4. The fourth case is a subset of the third one with the exception 275 that the intermediate nodes on the path from the WTP to the AC 276 may not necessarily be in the same administrative domain. The 277 intermediate network may also span one or more WAN links that may 278 have lower capacity than if both the AC and the WTP are within 279 the same building or campus. 281 +-----------------+ +-------+ 282 | | (1) | | 283 | AC +------------+ WTP | 284 | | | | 285 +--------+--------+ +-------+ 286 | 287 | 288 | 289 +---+---+ 290 (2) | | 291 +------+ L2 +--------+ 292 | | | | 293 | +---+---+ | 294 | | 295 | | 296 +-----+-----+ +---+---+ +-------+ 297 | | | | (3)| | 298 | WTP | | L3 +----+ WTP | 299 | | | | | | 300 +-----------+ +---+---+ +-------+ 301 | 302 | 303 | 304 +---+----+ +-------+ 305 | | (4)| | 306 |Internet+----+ WTP | 307 | | | | 308 +--------+ +-------+ 310 Figure 2: SLAPP Topology 312 4. Protocol 314 4.1 Protocol Description 316 The SLAPP state machine for both the WTP and AC is shown in Figure 3. 317 Both the WTP and the AC discover each other, negotiate a control 318 protocol, perform a secure handshake to establish a secure channel 319 between them, and then use that secure channel to protect a 320 negotiated control protocol. 322 The WTP maintains the following variable for its state machine: 324 abandon: a timer which sets the maximum amount of time the WTP will 325 wait for an acquired AC to begin the DTLS handshake. 327 /--------\ /-----------\ 328 | | | | 329 | v v | 330 | +-------------+ | 331 | C| discovering |<-\ | 332 | +-------------+ | | 333 | | | | 334 | v | | 335 | +-----------+ | | 336 \--| acquiring | | | 337 +-----------+ | | 338 | | | 339 v | | 340 +----------+ | | 341 C| securing |-----/ | 342 +----------+ | 343 | | 344 v | 345 +----------------+ | 346 | negotiated | | 347 C| control |-----/ 348 | protocol | 349 +----------------+ 351 Figure 3: SLAPP State Machine 353 4.1.1 State Machine Explanation 355 Note: the symbol "C" indicates an event which results in the state 356 remaining the same. 358 Discovering 360 AC: this is a quiescent state for the AC in which it waits for 361 WTPs to request its acquisition. When a request is received 362 the AC transitions to Acquiring. 364 WTP: the WTP is actively discovering an AC. When the WTP receives 365 a response to its discovery request it transitions to 366 Acquiring. 368 Acquiring 370 AC: a discover request from a WTP has been received. If the 371 request is invalid or the AC wishes to not acquire the WTP it 372 drops the packet and transitions back to Discovering. 373 Otherwise a discovery response is sent and the AC transitions 374 to Securing. 376 WTP: a discover response from an AC has been received. If the 377 response is not valid the WTP transitions to Discovering, 378 otherwise it sets the abandon timer to a suitable value to 379 await a DTLS exchange. If the timer fires in Acquiring the WTP 380 transitions back to Discovering. If a DTLS "client hello" is 381 received the WTP transitions to Securing and cancels the 382 abandon timer. 384 Securing 386 AC: The AC performs the "client end" of the DTLS exchange. Any 387 error in the DTLS exchange results in the AC transitioning to 388 Discovering. When the DTLS exchange finishes the AC 389 transitions to Negotiated Control Protocol. 391 WTP: The WTP performs the "server end" of the DTLS exchange. Any 392 error in the DTLS exchange results in the WTP transitioning to 393 Discovering. When the DTLS exchange finishes the WTP 394 transitions to the Negotiated Control Protocol. 396 Negotiated Control Protocol 398 AC: the AC performs its side of the protocol agreed to during the 399 discovery process. Please refer to Section 6.1 for the SLAPP 400 802.11 control protocol. For the Image Download Protocol 401 example see section Section 6.2. 403 WTP: the WTP performs its side of the protocol agreed to during 404 the discovery process. Please refer to Section 6.1 for the 405 SLAPP 802.11 control protocol. For the Image Download Protocol 406 example see section Section 6.2. 408 4.2 Format of a SLAPP Header 410 All SLAPP packets begin with the same header as shown in Figure 4. 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Maj | Min | Type | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 4: SLAPP Header 420 Where: 422 Maj (4 bits): the major number of the SLAPP version 424 Min (4 bits): the minor number of the SLAPP version 426 Type (1 octet): the type of SLAPP message 428 Length (two octets): the length of the SLAPP message, including 429 the entire SLAPP header 431 The following types of SLAPP messages have been defined: 433 name type 434 ------ ------ 435 discovery request 1 436 discovery response 2 437 image download control 3 438 control protocol packet 4 439 reserved 5-255 441 4.3 Version 443 SLAPP messages include a version in the form of major.minor. This 444 document describes the 1.0 version of SLAPP, that is the major 445 version is one (1) and the minor version is zero (0). 447 Major versions are incremented when the format of a SLAPP message 448 changes or the meaning of a SLAPP message changes such that it would 449 not be properly parsed by an older, existing version of SLAPP. Minor 450 versions are incremented when some incremental additions have been 451 made to SLAPP that enhance its capabilities or convey additional 452 information in a way that does not change the format or meaning of 453 the SLAPP message. 455 Future versions of SLAPP MAY NOT mandate support for earlier major 456 versions of SLAPP so an implementation MUST NOT assume that a peer 457 that supports version "n" will therefore support version "n - i" 458 (where both "n" and "i" are non-zero integers and "n" is greater than 459 "i"). 461 A SLAPP implementation that receives a SLAPP message with a higher 462 major version number MUST drop that message. A SLAPP implementation 463 that receives a SLAPP message with a lower major version SHOULD drop 464 down to the version of SLAPP the peer supports. If that version of 465 SLAPP is not supported the message MUST be dropped. There may be 466 valid reasons for which a peer wishes to drop a SLAPP message with a 467 supported major version though. 469 A SLAPP implementation that receives a SLAPP message with a higher 470 minor version number MUST NOT drop that message. It MUST respond 471 with the minor version number that it supports and will necessarily 472 not support whatever incremental capabilities were added that 473 justified the bump in the minor version. A SLAPP implementation that 474 receives a SLAPP message with a lower minor version MUST NOT drop 475 that message. It SHOULD revert back to the minor version which the 476 peer supports and not include any incremental capabilities that were 477 added which justified the bump in the minor version. 479 4.4 Retransmission 481 SLAPP is a request response protocol. Discovery and security 482 handshake requests are made by the WTP and responses to them are made 483 by the AC. Image download packets are initiated by the AC and 484 acknowledged by the WTP (in a negative fashion, see Section 6.2). 486 Retransmissions are handled solely by the initiator of the packet. 487 After each packet for which a response is required is transmitted, 488 the sender MUST set a retransmission timer and resend the packet upon 489 its expiry. The receiver MUST be capable of either regenerating a 490 previous response upon receipt of a retransmitted packet or caching a 491 previous response and resending upon receipt of a retransmitted 492 packet. 494 The retransmission timer MUST be configurable and default to one (1) 495 second. No maximum or minimum for the timer is specified by this 496 version of SLAPP. 498 Each time a retransmission is made a counter SHOULD be incremented 499 and the number of retransmissions attempted by a sender before giving 500 up and declaring a SLAPP failure SHOULD be four (4)-- that is, the 501 number of attempts made for each packet before declaring failure is 502 five (5). 504 The exception to this rule is Image Download packets which are not 505 individually acknowledged by the WTP (see Section 6.2). The final 506 packet is acknowledged and lost packets are indicated through Image 507 Download Requests. 509 4.5 Discovery 511 When a WTP boots up and wants to interoperate with an Access 512 Controller so that it can be configured by the AC, one of the first 513 things it needs to do is to discover one or more ACs in its network 514 neighborhood. This section contains the details of this discovery 515 mechanism. 517 As described in Section 3, an AC and a WTP could reside in the same 518 layer 2 domain, or be separated by a layer 3 cloud including 519 intermediate clouds that are not under the same administrative domain 520 (for example, an AC and a WTP separated by a wide-area public 521 network). So any proposed discovery mechanism should have provisions 522 to enable a WTP to discover an AC across all these topologies. 524 We assume that a WTP prior to starting the discovery process has 525 already obtained an IP address on its wired segment. 527 4.5.1 SLAPP Discover Request 529 The SLAPP discovery process is initiated by sending a SLAPP discover 530 request packet. The packet can be addressed to the broadcast IP 531 address, a well known multicast address, or (if the IP address of an 532 AC is either configured prior to the WTP booting up or is learned 533 during the boot-up sequence) addressed to a unicast IP address. Lack 534 of a response to one method of discovery SHOULD result in the WTP 535 trying another method of discovery. The SLAPP discover request 536 packet is a UDP packet addressed to port [TBD] designated as the 537 SLAPP discovery port. The source port can be any random port. The 538 payload of the SLAPP discover request packet is shown in Figure 5. 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Maj | Min | Type = 1 | Length | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Transaction ID | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | WTP Identifier | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | WTP Identifier (continued) | Flags | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | WTP Vendor ID | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | WTP HW Version | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | WTP SW Version | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | n controltypes| control type | . . . 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 Figure 5: SLAPP Discover Request 562 4.5.1.1 Transaction ID 564 The transaction ID is a randomly generated 32-bit number that is 565 maintained during one phase of the SLAPP discovery process. It is 566 generated by a WTP starting a discovery process. When one discovery 567 method fails to find an AC and the WTP attempts another discovery 568 method it MUST NOT reuse the Transaction ID. All ACs that intend to 569 respond to a SLAPP discover request must use the same value for this 570 field as in the request frame. 572 4.5.1.2 WTP Identifier 574 This field allows the WTP to specify a unique identifier for itself. 575 This MAY be, for instance, its 48-bit MAC address or it could be any 576 other string such as a serial number. 578 4.5.1.3 Flags 580 The flags field is used to indicate certain things about the discover 581 request. For example, bit 0 in the flags field indicates whether the 582 discover request packet is being sent to the AC, if unicast, based on 583 a configuration at the WTP or based on some other means of discovery. 584 This bit should always be set to the discover mode if the SLAPP 585 discover request packet is being sent to either a broadcast or 586 multicast address. Here are the valid values for various bits in the 587 Flags field. 589 Bit 0: 590 0 - Configuration mode 591 1 - Discover mode 593 Bits 1-15: 594 Must always be set to 0 by the transmitter 595 Must be ignored by the receiver 597 4.5.1.4 WTP Vendor ID 599 This 32-bit field is the WTP vendor's SMI enterprise code in network 600 octet order (these enterprise codes can be obtained from, and 601 registered with, IANA). 603 4.5.1.5 WTP HW Version 605 This 32-bit field indicates the version of hardware present in the 606 WTP. This is a number that is totally left to the WTP vendor to 607 choose. 609 4.5.1.6 WTP SW Version 611 This 32-bit field indicates the version of software present in the 612 WTP. This is a number that is totally left to the WTP vendor to 613 choose. 615 4.5.1.7 number of control types 617 This 8-bit field indicates the number of 8-bit control protocol 618 indicators that follow it and therefore implicitly indicates the 619 number of different control protocols the the WTP is capable of 620 supporting. This number MUST be at least one (1). 622 4.5.1.8 control types 624 This 8-bit field indicates the type of control protocol the WTP 625 supports and is willing to use when communicating with an AC. There 626 MAY be multiple "control type" indicators in a single SLAPP Discover 627 Request. 629 Valid control types 630 ------------------- 631 0 - RESERVED (MUST not be used) 632 1 - Image Download Control Protocol 633 2 - 802.11 SLAPP control protocol 634 3-255 - RESERVED (to IANA) 636 4.5.2 SLAPP Discover Response 638 An AC that receives a SLAPP discover request packet from a WTP can 639 choose to respond with a SLAPP discover response packet. The format 640 of the SLAPP discover response packet is shown in Figure 6. 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Maj | Min | Type = 2 | Length | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Transaction ID | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | WTP Identifier | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | WTP Identifier (continued) | Flags | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | AC HW Vendor ID | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | AC HW Version | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | AC SW Version | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | control type | 660 +-+-+-+-+-+-+-+-+ 662 Figure 6: SLAPP Discover Response 664 The SLAPP discover response packet is a UDP packet. It is always 665 unicast to the WTP's IP address. The source IP address is that of 666 the AC sending the response. The source port is the SLAPP discover 667 port [TBD] and the destination port is the same as the source port 668 used in the SLAPP discover request. The WTP's MAC address and the 669 transaction ID must be identical to the values contained in the SLAPP 670 discover request. The Status field indicates to the WTP whether the 671 AC is either accepting the discover request and is willing to allow 672 the WTP to proceed to the next stage (ACK) or whether it is denying 673 the WTP's earlier request (NACK). The AC includes its own vendor ID, 674 hardware and software versions in the response. 676 4.5.2.1 Transaction ID 678 The value of the Transaction ID field should be identical to its 679 value in the SLAPP discover request packet sent by the WTP. 681 4.5.2.2 WTP Identifier 683 The WTP Identifier that was sent in the corresponding SLAPP discover 684 request frame. 686 4.5.2.3 Flags 688 This field is unused by this version of SLAPP. It MUST be set to 689 zero (0) on transmission and ignored upon receipt. 691 4.5.2.4 AC Vendor ID 693 If the value of the status field is a 1, indicating that the AC is 694 sending a successful response, then the values in this field and the 695 following two are valid. The 32-bit AC Vendor ID points to the 696 vendor ID of the AC. If the value of the status field is not 1, then 697 this field should be set to 0 by the AC and ignored by the WTP. 699 4.5.2.5 AC HW Version 701 If the value of the status field is 1, then this 32-bit field 702 contains the value of the AC's hardware version. This value is 703 chosen by the AC vendor. If the value of the status field is not a 704 1, then this field should be set to 0 by the AC and ignored by the 705 WTP. 707 4.5.2.6 AC SW Version 709 If the value of the status field is 1, then this 32-bit field 710 contains the value of the AC's software version. This value is 711 chosen by the AC vendor. If the value of the status field is not a 712 1, then this field should be set to 0 by the AC and ignored by the 713 WTP. 715 4.5.2.7 Control Type 717 The control type the AC will use to communicate with the WTP. This 718 value MUST match one of the control types passed in the corresponding 719 SLAPP Discover Request. 721 4.6 SLAPP Discovery Process 722 4.6.1 WTP 724 There are multiple ways in which a WTP can discover an AC. 726 1. Static configuration: An administrator, prior to deploying a WTP, 727 can configure an IP address of an AC on the WTP's non-volatile 728 memory. If this is the case, then the SLAPP discover request 729 packet is addressed to the configured IP address. 731 2. DHCP options: As part of the DHCP response, the DHCP server could 732 be configured to use option 43 to deliver the IP address of an AC 733 to which the WTP should address the SLAPP discover request 734 packet. If the IP address of an AC is handed to the WTP as part 735 of the DHCP response, then the WTP should address the SLAPP 736 discover request packet to this IP address. 738 3. DNS configuration: Instead of configuring a static IP address on 739 the WTP's non-volatile memory, an administrator can configure a 740 FQDN of an AC. If the FQDN of an AC is configured, then the WTP 741 queries its configured DNS server for the IP address associated 742 with the configured FQDN of the AC. If the DNS query is 743 successful and the WTP acquires the IP address of an AC from the 744 DNS server, then the above discover request packet is addressed 745 to the unicast address of the AC. 747 4. Broadcast: The WTP sends a discover request packet addressed to 748 the broadcast IP address with the WTP's IP address as the source. 749 A network administrator, if necessary, could configure the 750 default router for the subnet that the WTP is on with a helper 751 address and unicast it to any address on a different subnet. 753 5. IP Multicast: A WTP can send the above payload to a SLAPP IP 754 multicast address [TBD]. 756 6. DNS: If there is no DNS FQDN configured on the WTP, and the WTP 757 is unable to discover an AC by any of the above methods, then it 758 should attempt to query the DNS server for a well known FQDN of 759 an AC [TBD]. If this DNS query succeeds, then the WTP should 760 address the SLAPP discover request packet to the unicast address 761 of the AC. 763 The above process is summarized in the sequence shown in Figure 7. 765 SLAPP discovery start: 766 Static IP address config option: 767 Is a static IP address for an AC configured? 768 If yes, send SLAPP discover request to that unicast IP address 769 SLAPP discover response within discovery_timer? 770 If yes, go to "done" 771 If not, go to "Static FQDN config option" 772 If not, go to "Static FQDN config option" 773 Static FQDN config option: 774 Is a static FQDN configured? 775 If yes, send a DNS query for the IP address for the FQDN. 776 Is DNS query successful? 777 If yes, send SLAPP discover request to that IP address 778 SLAPP discover response within discovery timer? 779 If yes, go to "done" 780 If not, go to "DHCP options option" 781 If not, go to "DHCP options option" 782 DHCP options option: 783 Is the IP address of an AC present in the DHCP response? 784 If yes, send SLAPP discover request to the AC's IP addr 785 SLAPP discover response within discovery timer? 786 If yes, go to "done" 787 If not, go to "Broadcast option" 788 If not, go to "Broadcast option" 789 Broadcast option: 790 Send SLAPP discover packet to the broadcast address 791 SLAPP discover response within discovery timer? 792 If yes, go to "done" 793 If not, go to "Multicast option" 794 Multicast option: 795 Send SLAPP discover packet to the SLAPP multicast address 796 SLAPP discover response within discovery timer? 797 If yes, go to "done" 798 If not, go to "DNS discovery option" 799 DNS discovery option: 800 Query the DNS server for a well known DNS name 801 Is the DNS discovery successful? 802 If yes, send SLAPP discover request to that IP addr 803 SLAPP discover response within discovery timer? 804 If yes, go to "done" 805 If not, go to "SLAPP discovery restart" 806 If not, go to "SLAPP discovery restart" 807 SLAPP discovery restart: 808 Set timer for SLAPP discovery idle timer 809 When timer expires, go to "SLAPP discovery start" 810 done: 811 go to the next step 812 Figure 7 814 4.6.2 AC 816 When an AC receives a SLAPP discover request it must determine 817 whether it wishes to acquire the WTP or not. An AC MAY only agree to 818 acquire those WTPs whose WTP Identifiers are statically configured in 819 its configuration. Or an AC that is willing to gratuitously acquire 820 WTPs MAY accept any request pending authentication. An AC MUST only 821 choose to acquire WTPs that speak a common Negotiated Control 822 protocol but other factors may influence its decision. For instance, 823 if the Negotiated Control Protocol is the Image Download protocol 824 defined in this memo the AC MUST NOT acquire a WTP for which it does 825 not have a compatible image to download as determined by the WTP's HW 826 Vendor ID, HW Version and Software Version. Whatever its decision, 827 the AC MUST respond one of two ways. 829 1. The AC sends a SLAPP discover response indicating its agreement 830 to acquire the WTP. 832 2. The AC silently drops the SLAPP discover request and does not 833 respond at all. 835 5. Security Association 837 Once an AC has been discovered by a WTP and agreed to acquire it (by 838 sending a Discovery Response) it will initiate a DTLS [7] [9] 839 exchange with the WTP by assuming the role of the "client". The WTP 840 assumes the role of the "server". The port used by both the WTP and 841 AC for this exchange will be [TBD]. 843 An obvious question is "why is the AC acting as a client?" The 844 reason is to allow for non-mutual authentication in which the WTP is 845 authenticated by the AC (see Section 5.1.2). 847 Informational note: DTLS is used because it provides a secure and 848 connectionless channel using a widely accepted and analyzed protocol. 849 In addition, the myriad of authentication options in DTLS allows for 850 a wide array of options with which to secure the channel between the 851 WTP and the AC-- mutual and certificate based; asymmetric or non- 852 mutual authentication; anonymous authentication; etc. Furthermore, 853 DTLS defines its own fragmentation and reassembly techniques as well 854 as ways in which peers agree on an effective MTU. Using DTLS 855 obviates the need to redefine these aspects of a protocol and 856 therefore lessens code bloat as the same problem doesn't need to be 857 solved yet again in another place. 859 Failure of the DTLS handshake protocol will cause both parties to 860 abandon the exchange. The AC SHOULD blacklist this WTP for a period 861 of time to prevent a misconfigured WTP from repeatedly discovering 862 and failing authentication. The WTP MUST return to the discovery 863 state of SLAPP to locate another suitable AC with which it will 864 initiate a DTLS exchange. 866 Once the DTLS handshake has succeeded the WTP and AP transition into 867 "image download state" and protect all further SLAPP messages with 868 the DTLS-negotiated cipher suite. 870 5.1 Example Authentication Models (Informative) 872 Any valid cipher suite in [8] can be used to authenticate the WTP 873 and/or the AC. Different scenarios require different authentication 874 models. The following examples are illustrative only and not meant 875 to be exhaustive. 877 Since neither side typically involves a human being a username/ 878 password based authentication is not possible. 880 Zero-config requirements on certain WTP deployments can predicate 881 certain authentication options and eliminate others. 883 5.1.1 Mutual Authentication 885 When mutually authenticating, the WTP authenticates the AC, thereby 886 ensuring that the AC to which it is connecting is a trusted AC, and 887 the AC authenticates the WTP, thereby ensuring that the WTP that is 888 connecting is a trusted WTP. 890 Mutual authentication is typically achieved by using certificates on 891 the WTP and AC which ensure public keys each party owns. These 892 certificates are digitally signed by a Certification Authority, a 893 trusted third party. 895 Enrolling each WTP in a Certification Authority is outside the scope 896 of this document but it should be noted that a manufacturing 897 Certification Authority does not necessarily provide the level of 898 assurance necessary as it will only guarantee that a WTP or AC was 899 manufactured by a particular company and cannot distinguish between a 900 trusted WTP and a WTP which is not trusted but was purchased from the 901 same manufacturer as the AC. 903 5.1.2 WTP-only Authentication 905 Some deployments may only require the WTP to authenticate to the AC 906 and not the other way around. 908 In this case the WTP has a keypair which can uniquely identify it 909 (for example, using a certificate) and that keypair is used in a 910 "server-side authentication" [8] exchange. 912 This authentication model does not authenticate the AC and a rogue AC 913 could assert control of a valid WTP. It should be noted, though, 914 that this will only allow the WTP to provide service for networks 915 made available by the rogue AC. No unauthorized network access is 916 possible. 918 5.1.3 Anonymous Authentication 920 In some deployments it MAY just be necessary to foil the casual 921 snooping of packets. In this case an unauthenticated, but encrypted, 922 connection can suffice. Typically a Diffie-Hellman exchange is 923 performed between the AC and WTP and the resulting unauthenticated 924 key is used to encrypt traffic between the AC and WTP. 926 6. SLAPP Control Protocols 928 In this section, we describe two extensions for SLAPP - one that is 929 specific to 802.11 WLANs and another that is a technology neutral 930 protocol by which an AC can download a bootable image to a WTP. 932 6.1 802.11 Control Protocol for SLAPP 934 This section describes a SLAPP extension that is targeted towards 935 WTPs and ACs implementing the IEEE 802.11 WLAN standard. This 936 extension contains all the technology-specific component that will be 937 used by an AC to control and manage 802.11 WTPs. 939 6.1.1 Suppported CAPWAP Architectures 941 The CAPWAP architecture taxonomy document [2] describes multiple 942 architectures that are in use today in the WLAN industry. While 943 there is a wide spectrum of variability present in these documented 944 architectures, supporting every single variation or choice would lead 945 to a complex protocol and negotiation phase. In the interest of 946 limiting the complexity of the 802.11 component, we have limited the 947 negotiation to four different architectural choices as listed below. 949 Local MAC, bridged mode : This mode of operation falls under the 950 Local MAC architecture. The 802.11 MAC is terminated at the WTP. 951 The WTP implements an L2 bridge that forwards packets between its 952 WLAN interface and its ethernet interface. 954 Local MAC, tunneled mode : This mode of operation also falls under 955 the Local MAC architecture where the 802.11 MAC is terminated at 956 the WTP. The difference between this mode and the previous one is 957 that in this mode, the WTP tunnels 802.3 frames to the AC using 958 the mechanisms defined in Section 6.1.2. 960 Split MAC, L2 crypto at WTP : This mode of operation falls under the 961 split MAC architecture. The 802.11 MAC is split between the WTP 962 and the AC, the exact nature of the split is described in 963 Section 6.1.1.2. The L2 crypto functions are implemented in the 964 WTP are the ones used to satisfy this function irrespective of 965 whether the AC is also capable of this function or not. The WTP 966 tunnels L2 frames to the AC using mechanisms defined in 967 Section 6.1.2. 969 Split MAC, L2 crypto at AC : This mode of operation also falls under 970 the split MAC architecture. The difference between this one and 971 the previous one is that the L2 crypto functions implemented in 972 the AC are used to satisfy this function irrespective of whether 973 these functions are also available at the WTP or not. The WTP 974 tunnels L2 frames to the AC using mechanisms defined in 975 Section 6.1.2. 977 6.1.1.1 Local MAC 979 The Local MAC architecture as documented in the CAPWAP architecture 980 taxonomy document [2] performs all 802.11 frame processing at the 981 WTP. The conversion from 802.11 to 802.3 and vice-versa is also 982 implemented at the WTP. This would mean that other functions like 983 fragmentation/reassembly of 802.11 frames, encryption/decryption of 984 802.11 frames is implemented at the WTP. 986 6.1.1.1.1 Bridged Mode 988 In this sub-mode of the Local MAC architecture, the 802.11 frames are 989 converted to 802.3 frames and bridged onto the Ethernet interface of 990 the WTP. These frames may be tagged with 802.1Q VLAN tags assigned 991 by the AC. 993 6.1.1.1.2 Tunneled Mode 995 In this sub-mode of the Local MAC architecture, the 802.11 frames are 996 converted to 802.3 frames and are tunneled (using the tunneling 997 mechanism defined in Section 6.1.2) to the AC that the WTP is 998 attached to. These frames may be tagged with 802.1Q VLAN tags 999 assigned by the AC. 1001 6.1.1.2 Split MAC 1003 In the split MAC architecture, the MAC functions of an 802.11 AP are 1004 split between the WTP and the AC. The exact nature of the split is 1005 dependent upon the sub-modes listed in this section. In both cases, 1006 frames are tunneled to the AC using the mechanism defined in 1007 Section 6.1.2. 1009 Some of these split MAC architectures convert the 802.11 frames into 1010 802.3 frames, which may be 802.1Q tagged using tags assigned by the 1011 AC, while other of these split MAC architectures will tunnel the 1012 entire 802.11 frame to the AC. The AC and WTP agree on what type of 1013 frame will be tunneled during the control protocol registration 1014 Section 6.1.3 1016 6.1.1.2.1 L2 Crypto at the WTP 1018 For this sub-mode of the split MAC architecture, the 802.11 AP 1019 functions are split as follows: 1021 At the WTP 1023 802.11 control frame processing 1025 802.11 encryption and decryption 1027 802.11 fragmentation and reassembly 1029 Rate Adaptation 1031 802.11 beacon generation 1033 Power-save buffering and TIM processing 1035 At the AC 1037 802.11 Management frame processing 1039 802.11 DS and portal 1041 Split MAC implementations of this kind may tunnel either 802.11 or 1042 802.3 frames between the AC and the WTP. 1044 6.1.1.2.2 L2 Crypto at the AC 1046 For this sub-mode of the split MAC architecture, the 802.11 AP 1047 functions are split as follows: 1049 At the WTP 1051 802.11 control frame processing 1053 Rate Adaptation 1055 802.11 beacon generation 1057 Power-save buffering and TIM processing 1059 At the AC 1061 802.11 Management frame processing 1063 802.11 encryption and decryption 1065 802.11 fragmentation and reassembly 1066 802.11 DS and portal 1068 Split MAC implementations of this kind tunnel 802.11 frames between 1069 the AC and the WTP. 1071 6.1.2 Transport 1073 The 802.11 Control protocol has two components, one for transporting 1074 the specific control and provisioning messages and another to tunnel 1075 data traffic from the WTP to the AC. 1077 The SLAPP 802.11 Control Protocol uses the Generic Routing 1078 Encapsulation (GRE) [4] to encapsulate L2 frames. Depending on 1079 whether and how an architecture splits its MAC some architectures may 1080 tunnel 802.11 frames directly to the AC while others may tunnel 802.3 1081 frames which may be optionally 802.1Q tagged using tags assigned by 1082 the AC. 1084 The delivery mechanism of these GRE packets is IP. Therefore the IP 1085 protocol of the outer packet is 47, indicating a GRE header follows. 1086 When GRE encapsulates 802.11 frames the ether type in the GRE header 1087 is TBD; when GRE encapsulates 802.3 frames the ether type in the GRE 1088 header is TBD2. 1090 Since IP is the delivery mechanism all issues governing fragmentation 1091 and reassembly are handled by [5]. 1093 6.1.2.1 SLAPP 802.11 Control Protocol Header 1095 When using the 802.11 control protocol the type of SLAPP message is 1096 four (4), "control protocol packet". In this case a two (2) octet 1097 field is appended to the SLAPP header to indicate the control 1098 protocol type as shown in Figure 8. The SLAPP 802.11 Control 1099 Protocol takes place in the "negoatiated control protocol" phase of 1100 Section 4.1 and all SLAPP 802.11 Control Protocol messages are 1101 therefore secured by the security association created immediately 1102 prior to entering that phase. 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Maj | Min | 4 | Length | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | 802.11 Control Protocol Type | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 Figure 8: SLAPP Control Protocol Header 1114 Where valid 802.11 Control Protocol Types are: 1116 1 : Registration request - sent from WTP to AC 1118 2 : Registration response - sent from AC to WTP 1120 3 : De-registration request - sent by either WTP or AC 1122 4 : De-registration response - sent by the recipient of the 1123 corresponding request 1125 5 : Configuration request - sent by WTP to AC 1127 6 : Configuration response - sent by AC to WTP 1129 7 : Configuration update - sent by AC to WTP 1131 8 : Configuration acknowledgment - sent by the WTP to AC 1133 9 : Status request - sent by the AC to the WTP 1135 10 : Status response - sent by the WTP to the AC 1137 11 : Statistics request - sent by the AC to the WTP 1139 12 : Statistics response - sent by the WTP to the AC 1141 13 : Event - sent by the WTP to the AC 1143 14 : Keepalive - sent either way 1145 15 : Key Config Request - sent by the AC to the WTP 1147 16 : Key Config Response - sent by the WTP to the AC 1149 6.1.3 Provisioning and Configuration of WTP 1151 All basic configuration functions are applicable per-ESSID per-radio 1152 in a WTP. Some WTPs MAY support more than one ESSID per-radio, while 1153 all WTPs MUST support at least one ESSID per-radio, which may be 1154 considered the primary ESSID in case of multiple ESSID support. All 1155 per-WTP configurations and capabilities (e.g., number of radios) are 1156 handled as part of the discovery and initialization process. 1158 The provisioning of the regulatory domain of a WTP is beyond the 1159 scope of this document. A WTP, once provisioned for a specific 1160 regulatory domain MUST restrict the operational modes, channel, 1161 transmit power and any other necessary limits based on the knowledge 1162 contained within its software image and hardware capabilities. The 1163 WTP MUST communicate its capabilities limited by the regulatory 1164 domain as well as by the WTP hardware, if any, to the AC during the 1165 capability exchange. 1167 The allocation and assignment of BSSIDs to the primary interface and 1168 to the virtual AP interfaces, if supported, are outside the scope of 1169 this document. 1171 6.1.3.1 Information Elements 1173 Information elements are used to communicate capability, 1174 configuration, status, and statistics information between the AC and 1175 the WTP. 1177 6.1.3.1.1 Structure of an Information Element 1179 The structure of an information element is show below. The element 1180 ID starts with an element ID octet, followed by a 1-octet length and 1181 the value of the element ID whose length is indicated in the Length 1182 field. The maximum length of an element is 255 octets. 1184 0 1 2 3 1185 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 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Element ID | Length | Value .... | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 6.1.3.1.2 CAPWAP Mode 1192 This element defines the MAC architecture modes (Section 6.1.1). 1194 Element ID : 1 1196 Length : 1 1198 Value : The following values are defined. 1200 Bit 0 : CAPWAP mode 1 - Local MAC, bridged mode 1202 Bit 1 : CAPWAP mode 2 - Local MAC, tunneled mode 1204 Bit 2 : CAPWAP mode 3 - Split MAC, WTP encryption, 802.3 tunneling 1205 Bit 3 : CAPWAP mode 4 - Split MAC, WTP encryption, 802.11 1206 tunneling 1208 Bit 4 : CAPWAP mode 5 - Split MAC, AC encryption, 802.11 tunneling 1210 Bits 5-7 : set to 0 1212 When this element is included in the capabilities message, then the 1213 setting of a bit indicates the support for this CAPWAP mode at the 1214 WTP. When this element is used in configuration and status messages, 1215 then exactly one of bits 0-4 MUST be set. 1217 6.1.3.1.3 Number of WLAN Interfaces 1219 This element refers to the number of 802.11 WLAN present in the WTP. 1221 Element ID : 2 1223 Length : 1 1225 Value : 0-255 1227 6.1.3.1.4 WLAN Interface Index 1229 This element is used to refer to a particular instance of a WLAN 1230 interface when used in configuration and status messages. When used 1231 within a recursion element, the elements within the recursion element 1232 correspond to the WLAN interface specified in this element. 1234 Element ID : 3 1236 Length : 1 1238 Value : 0 - (Number of WLAN interfaces - 1) 1240 6.1.3.1.5 WLAN Interface Hardware Vendor ID 1242 This element is the WLAN Interface hardware vendor's SMI enterprise 1243 code in network octet order (these enterprise codes can be obtained 1244 from, and registered with, IANA). This field appears once for each 1245 instance of WLAN interface present in the WTP. 1247 Element ID : 4 1249 Length : 4 1250 Value : 32-bit value 1252 6.1.3.1.6 WLAN Interface Type ID 1254 This element is an ID assigned by the WLAN Interface hardware vendor 1255 to indicate the type of the WLAN interface. It is controlled by the 1256 hardware vendor and the range of possible values is beyond the scope 1257 of this document. This field appears once for each instance of WLAN 1258 interface present in the WTP. 1260 Element ID : 5 1262 Length : 4 1264 6.1.3.1.7 Regulatory Domain 1266 If a regulatory domain is provisioned in the WTP, then the WTP 1267 indicates this by including this element in the capabilities list. 1268 If this information is not available at the WTP, then this element 1269 SHOULD not be included in the capabilities list. The process by 1270 which this information is provisioned into the WTP is beyond the 1271 scope of this document. 1273 Element ID : 6 1275 Length : 4 1277 Value : ISO code assigned to the regulatory domain 1279 6.1.3.1.8 802.11 PHY mode and Channel Information 1281 This element indicates the list of 802.11 PHY modes supported by the 1282 WTP along with a list of channels and maximum power level supported 1283 for this mode. This element appears once for each instance of WLAN 1284 interface at the WTP. There could be multiple instances of this 1285 element if the WLAN interface supports multiple PHY types. 1287 Element ID : 7 1289 Length : Variable 1291 Valid : This field consists of 1292 PHY mode : With a length of 1 octet with value values as follows: 1294 0 : Radio Disabled/Inactive 1296 1 : IEEE 802.11b 1298 2 : IEEE 802.11g 1300 3 : IEEE 802.11a 1302 4-255 : Reserved 1304 Power Level : In the capabilities messages, this indicates the 1305 maximum power level supported in this mode by the WTP, while in 1306 the configuration and status messages this field indicates the 1307 desired power level or the current power level that the WTP is 1308 operating at. The field has a length of 1 octet and the power 1309 level is indicated in dBm. 1311 Channel Information : A variable number of 2-octet values that 1312 indicate the center frequencies (in KHz) of all supported 1313 channels in this PHY mode. 1315 When this element is used in configuration and status messages, the 1316 power level field indicates the desired or current operating power 1317 level. The channel field has exactly one 2-octet value indicating 1318 the desired or current operating frequency. 1320 6.1.3.1.9 Cryptographic Capability 1322 In the capabilities message, this element contains the list of 1323 cryptographic algorithms that are supported by the WTP. This appears 1324 once for each instance of the WLAN interface present in the WTP. In 1325 configuration and status messages, this element is used to indicate 1326 the configured cryptographic capabilities at the WTP. 1328 Element ID : 8 1330 Length : 1 1332 Value : The following bits are defined. 1334 Bit 0 : WEP 1336 Bit 1 : TKIP 1338 Bit 2 : AES-CCMP 1339 Bits 3-7 : Reserved 1341 6.1.3.1.10 Other IEEE 802.11 Standards Support 1343 This element contains a bitmap indicating support at the WTP for 1344 various IEEE 802.11 standards. 1346 Element ID : 9 1348 Length : 4 1350 Value : A bitmap as follows 1352 Bit 0 : WPA 1354 Bit 1 : 802.11i 1356 Bit 2 : WMM 1358 Bit 3 : WMM-SA 1360 Bit 4 : U-APSD 1362 Bits 5-32 : Reserved 1364 6.1.3.1.11 Antenna Information Element 1366 In the capabilities message, this element is formatted as follows 1368 Element ID : 10 1370 Length : 4 1372 Value : Formatted as follows 1374 Bits 0-7 : Number of Antennae 1376 Bit 8 : Individually Configurable, 0 = No, 1 = Yes 1378 Bit 9 : Diversity support, 0 = No, 1 = Yes 1380 Bit 10 : 0 = Internal, 1 = External 1382 Bits 11-31 : Reserved 1384 In configuration and status messages, this element is formatted as 1385 follows: 1387 Element ID : 10 1389 Length : 4 1391 Value : Formatted as follows 1393 Bits 0-7 : Antenna Number - is a number between 0 and the 1394 number of antennae indicated by the WTP. The value is valid 1395 only if Bit 8 is set, otherwise it MUST be ignored 1397 Bit 8 : Antenna Select - if this bit is reset then the antenna 1398 selection is left to the algorithm on the WTP. If this bit is 1399 set, then the Antenna Number field indicates the antenna that 1400 should be used for transmit and receive. 1402 Bits 9-31 : Reserved 1404 6.1.3.1.12 Number of BSSIDs 1406 This element indicates the number of BSSIDs supported by the WLAN 1407 interface. This element is optional in the capabilities part of the 1408 registration request message and if it is absent, then the number of 1409 BSSIDs is set to 1. This element appears once for each instance of a 1410 WLAN interface present in the WTP. 1412 Element ID : 11 1414 Length : 1 1416 Value : The number of BSSIDs that the WLAN interface is capable of 1417 supporting. 1419 6.1.3.1.13 BSSID Index 1421 This element is used when sending configuration or status specific to 1422 a certain BSSID in the WTP. 1424 Element ID : 12 1426 Length : 1 1428 Valid values are from 0 to (Number of BSSIDs -1) 1430 6.1.3.1.14 ESSID 1432 This element is used in configuration and status messages to either 1433 configure the ESSID on a certain BSSID or report the current 1434 operating value. 1436 Element ID : 13 1438 Length : Variable, between 0 and 32 both inclusive 1440 Value : Variable, contains ASCII characters. 1442 There is no default value for this parameter. 1444 6.1.3.1.15 ESSID Announcement Policy 1446 This element is used in configuration and status messages to control 1447 the announcement of the ESSID in 802.11 beacons. For the local MAC 1448 modes of operation, this field is also used to control whether the 1449 WTP should respond to probe requests that have a NULL ESSID in them. 1451 Element ID : 14 1453 Length : 1 1455 Value : Defined as follows 1457 Bit 0 : ESSID announcement, 0 = Hide ESSID, 1 = Display ESSID in 1458 802.11 beacons. The default value for this bit is 1. 1460 Bit 1 : Probe Response policy, 0 = Respond to probe requests that 1461 contain a NULL ESSID, 1 = Respond only to probe requests that 1462 match the configured ESSID. The default value for this bit is 1463 0. 1465 Bit 2-7 : Reserved 1467 6.1.3.1.16 Beacon Interval 1469 This element is used to configure the beacon interval on a BSSID on 1470 the WTP. 1472 Element ID : 15 1474 Length : 2 1475 Value : Valid values for the beacon interval as allowed by IEEE 1476 802.11 1478 The default value for this parameter is 100. 1480 6.1.3.1.17 DTIM period 1482 This element is used to configure the DTIM period on a BSSID present 1483 on the WTP. 1485 Element ID : 16 1487 Length : 2 1489 Value : Valid values for the DTIM period as allowed by IEEE 802.11 1491 The default value for this parameter is 1. 1493 6.1.3.1.18 Basic Rates 1495 Configure or report the configured set of basic rates. 1497 Element ID : 17 1499 Length : 4 1501 Value : Each of the bits in the following list is interpreted as 1502 follows. If the bit is set, then that particular rate is to be 1503 configured as a basic rate. If the bit is reset, then the rate is 1504 not to be configured as a basic rate. 1506 Bit 0 : 1 Mbps 1508 Bit 1 : 2 Mbps 1510 Bit 2 : 5.5 Mbps 1512 Bit 3 : 11 Mbps 1514 Bit 4 : 6 Mbps 1516 Bit 5 : 9 Mbps 1518 Bit 6 : 12 Mbps 1520 Bit 7 : 18 Mbps 1521 Bit 8 : 24 Mbps 1523 Bit 9 : 36 Mbps 1525 Bit 10 : 48 Mbps 1527 Bit 11 : 54 Mbps 1529 Bits 12-31 : Reserved 1531 6.1.3.1.19 Supported Rates 1533 Configure or report the configured set of basic rates. 1535 Element ID : 18 1537 Length : 4 1539 Value : Each of the bits in the following list is interpreted as 1540 follows. If the bit is set, then that particular rate is to be 1541 configured as a supported rate. If the bit is reset, then the 1542 rate is not to be configured as a supported rate. 1544 Bit 0 : 1 Mbps 1546 Bit 1 : 2 Mbps 1548 Bit 2 : 5.5 Mbps 1550 Bit 3 : 11 Mbps 1552 Bit 4 : 6 Mbps 1554 Bit 5 : 9 Mbps 1556 Bit 6 : 12 Mbps 1558 Bit 7 : 18 Mbps 1560 Bit 8 : 24 Mbps 1562 Bit 9 : 36 Mbps 1564 Bit 10 : 48 Mbps 1566 Bit 11 : 54 Mbps 1567 Bits 12-31 : Reserved 1569 6.1.3.1.20 802.11 Retry Count 1571 This element is used to configure long and short retries for each 1572 BSSID present on the WTP. 1574 Element ID : 19 1576 Length : 2 1578 Value : as follows 1580 Bits 0-7 : Short retry count, default value is 3. 1582 Bits 8-15 : Long retry count, default value is 3. 1584 6.1.3.1.21 Fragmentation Threshold 1586 This element is used to configure the fragmentation threshold on a 1587 BSSID present on the WTP. 1589 Element ID : 20 1591 Length : 2 1593 Value : Valid values for the fragmentation threshold as allowed by 1594 IEEE 802.11. 1596 The default value for this parameter is 2346. 1598 6.1.3.1.22 RTS Threshold 1600 This element is used to configure the RTS threshold on a BSSID 1601 present on the WTP. 1603 Element ID : 21 1605 Length : 2 1607 Value : Valid values for RTS threshold as allowed by IEEE 802.11. 1609 The default value for this parameter is 2346. 1611 6.1.3.1.23 Short/Long Preamble 1613 This element is used to configure the preamble type used for 1614 transmission in 802.11b mode. 1616 Element ID : 22 1618 Length : 1 1620 Value : defined as follows 1622 0 : Disable Short preamble 1624 1 : Enable Short preamble 1626 2-255 : Reserved 1628 The default value for this parameter is 0. 1630 6.1.3.1.24 802.1Q Tag 1632 This element is used to configure the tagging of packets belonging to 1633 a particular SSID when transfered between the AC and the WTP in 1634 CAPWAP modes 2-3, or before the WTP bridges the 802.3 frame to its 1635 wired interface when operating in CAPWAP mode 1. 1637 Element ID : 23 1639 Length : 2 1641 Value : 802.1Q tag 1643 If this element is absent in the configuration, then the WTP MUST 1644 assume that no tagging is required and should expect to receive 1645 untagged frames on frames destined towards the wireless interface. 1647 6.1.3.1.25 SLAPP Registration ID 1649 A successful registration response from an AC to a WTP MUST contain 1650 this element. It is used in messages between the WTP and the AC on 1651 all other messages during the duration for which the registration is 1652 active. 1654 Element ID : 24 1656 Length : 4 1657 Value : a 32-bit unsigned number allocated by the AC 1659 6.1.3.1.26 WTP Name 1661 The AC uses this element to assign a string of ASCII characters to 1662 the WTP. 1664 Element ID : 25 1666 Length : Variable, between 0 and 64 both inclusive 1668 Value : A variable length string of ASCII characters 1670 6.1.3.1.27 Event Filter 1672 The AC uses this element to assign importance to events, enable or 1673 disable notification, and to configure the global event notification 1674 policy. When the Event Identifier is 0, this element serves as a 1675 global notification policy message. The bitmap indicates the types 1676 of events that require the WTP to generate a notification. When the 1677 Event Identifier is non-zero, this element is used to configure a 1678 specific event for notification and its importance level. The 1679 importance level is specified by setting exactly one bit in the 1680 bitmap. If none of the bits are set in the bitmap, the element 1681 should be interpreted as a cancellation request. The WTP should stop 1682 sending notifications for the corresponding event specified in the 1683 Element Identifier. 1685 Element ID : 26 1687 Length : 4 1689 Value : defined as follows 1691 Bits 0 - 15: Event Identifier 1693 Bit 16: Fatal - The system is not usable 1695 Bit 17: Alert - Immediate action is required 1697 Bit 18: Critical 1699 Bit 19: Error 1701 Bit 20: Warning 1702 Bit 21: Notification 1704 Bit 22: Informational 1706 Bit 23: Debug 1708 Bits 24 - 31: Reserved 1710 6.1.3.1.28 Radio Mode 1712 The AC uses this element to indicate the mode of operation for the 1713 radio for each WLAN interface. 1715 Element ID : 27 1717 Length : 1 1719 Value : The following are valid values. 1721 0 : Radio is disabled 1723 1 : Radio is enabled 1725 2-255 : Reserved 1727 6.1.3.1.29 IEEE 802.11e Element 1729 The AC uses this element to configure 802.11e functions at the WTP 1731 Element ID : 28 1733 Length : 4 1735 Value : A bitmap as follows 1737 Bit 0 : WMM 1739 Bit 1 : WMM-SA 1741 Bit 2 : U-APSD 1743 Bits 3-32 : Reserved 1745 6.1.3.1.30 Configuration Statistics 1747 This element defines the statistics relating to configuration and 1748 registration events as seen by the WTP. 1750 Element ID : 29 1752 Length : 32 1754 Value : The value is as follows. 1756 * Configuration Requests : 4 octets - Number of configuration 1757 request messages sent by the WTP since the last reboot or reset 1758 of the counters 1760 * Configuration Responses : 4 octets 1762 * Configuration Updates : 4 octets 1764 * Configuration ACKs : 4 octets 1766 * Registration Requests : 4 octets 1768 * Registration Responses : 4 octets 1770 * De-registration requests : 4 octets 1772 * De-registration responses : 4 octets 1774 6.1.3.1.31 Transmit Frame Counters 1776 This information element contains a set of counters relating to the 1777 transmit side of the wireless link at the WTP. These counters apply 1778 to either a BSS or an Access Category (if WMM is enabled). 1780 Element ID : 30 1782 Length : 112 octets 1784 Value : The value of this element is defined as follows. 1786 * Total received from the network : 4 octets 1788 * Successfully transmitted frames (total) : 4 octets 1790 * Successfully transmitted 802.11 Mgmt frames : 4 octets 1791 * Successfully transmitted 802.11 Data frames : 4 octets 1793 * Transmitted 802.11 Control frames : 4 octets 1795 * Frames that reached max-retry limit : 4 octets 1797 * Transmitted frames with 1 retry attempt : 4 octets 1799 * Transmitted frames with 2 retry attempts : 4 octets 1801 * Transmitted frames with more than 2 retry attempts : 4 octets 1803 * Frames transmitted at each 802.11 PHY rate : 12*4 octets - The 1804 counters indicate the number of frames at each of the following 1805 rates respectively : 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 1806 54 Mbps 1808 * Total frame dropped : 4 octets 1810 * Frames dropped due to insufficient resources : 4 octets 1812 * Frames dropped due to power-save timeouts : 4 octets 1814 * Frames dropped due to other reasons : 4 octets 1816 * Fragments Transmitted : 4 octets 1818 * Fragments dropped : 4 octets 1820 * Power-save multicast frames : 4 octets 1822 * Power-save unicast frames : 4 octets 1824 6.1.3.1.32 Received Frame Counters 1826 This information element includes all statistics related to the 1827 reception of the frames by WTP. These counters apply to either a BSS 1828 or an Access Category (if WMM is enabled). 1830 Element ID : 31 1832 Length : 108 octets 1834 Value : The value of this element is defined as follows. 1836 * Total Frames received : 4 octets 1837 * Frames with the retry bit set : 4 octets 1839 * 802.11 Data frames received : 4 octets 1841 * 802.11 Mgmt frames received : 4 octets 1843 * 802.11 Control frames received : 4 octets 1845 * CRC errors : 4 octets 1847 * PHY errors : 4 octets 1849 * Total Fragments received : 4 octets 1851 * Reassembled frames : 4 octets 1853 * Reassembly failures : 4 octets 1855 * Successful Decryption : 4 octets 1857 * Decryption failures : 4 octets 1859 * Rate statistics : 48 octets - the number of frames received at 1860 each of the 802.11 PHY rates respectively - 1, 2, 5.5, 11, 6, 1861 9, 12, 18, 24, 36, 49, 54 Mbps 1863 * Total frames dropped : 4 octets 1865 * Frames dropped due to insufficient resources : 4 octets 1867 * Frames dropped due to other reasons : 4 octets 1869 6.1.3.1.33 Association Statistics 1871 This element includes information about the current stations 1872 associated with the BSS. 1874 Element ID : 32 1876 Length : Variable 1878 Value : The value is defined as follows. 1880 * Total association requests : 4 octets 1882 * Total associations accepted : 4 octets 1883 * Total associations rejected : 4 octets 1885 * Current associations : 4 octets 1887 * For each associated station, 1889 + Station MAC address : 6 octets 1891 + Power save state : 1 octet 1893 + Current Tx rate : 1 octet 1895 + Rate of last packet : 1 octet 1897 + Preamble type : 1 octet 1899 + WMM/U-APSD state : ?? octet 1901 6.1.3.1.34 Status Element 1903 The status IE is included in the status response message sent by the 1904 WTP to the AC. It contains a set of fields that are used to indicate 1905 the status of various states at the WTP or each BSS configured in the 1906 WTP. 1908 Element ID : 33 1910 Length : 2 octets 1912 Value : The value is defined as follows. 1914 ERP element, if applicable. If not applicable, then this field 1915 MUST be set to 0 1917 Noise Floor : 1 octet 1919 6.1.3.1.35 Event Configuration 1921 This element is used by the AC to configure the set of events that it 1922 wants to be notified by the WTP. 1924 Element ID : 34 1926 Length : 4 octets 1927 Value : The value is defined as follows. 1929 * Radar Detection - 1 octet 1931 + Bit 0 : 1 = notify on detecting radar interference, 0 1932 otherwise 1934 + Bit 1 : 1 = notify of channel change due to radar 1935 interference, 0 otherwise 1937 + All other bits are reserved. 1939 * Excessive Retry Event - 1 octet. Number of successive frames 1940 that have not been acknowledged by a client. A value of 0 1941 disables notification. 1943 * Noise Floor Threshold - 1 octet. Defines the threshold above 1944 which an event would be generated by the WTP. 1946 * 802.11 Management and Action Frame Notification - 1 octet. 1948 + Bit 0 : If set, notify AC of probe requests from stations 1949 (please use with caution). If reset, then no probe response 1950 notification is needed. 1952 + Bit 1 : If set, the WTP should notify the AC of all other 1953 management frames from stations. 1955 + All other bits are reserved. 1957 6.1.3.1.36 Radar Detection Event 1959 This element is used by the WTP to notify the AC of detection of 1960 radar interference and any channel changes as a result of this 1961 detection. 1963 Element ID : 35 1965 Length : 10 octets 1967 Value : defined as follows. 1969 BSSID : 6 octets. The BSSID of the WLAN interface that 1970 detected the radar interference. 1972 Channel : 2 octets. The channel on which radar interference 1973 was detected. 1975 New Channel : 2 octets. The new channel to which the WTP moved 1976 as a result of detection of radar interference. 1978 6.1.3.1.37 Excessive Retry Event 1980 This element is used by the WTP to indicate excessive retry events on 1981 transmission to an associated station. 1983 Element ID : 36 1985 Length : 14 octets 1987 Value : defined as follows. 1989 Station MAC : 6 octets 1991 Associated BSSID : 6 octets 1993 Length of last burst of excessive retries : 2 octets. 1995 6.1.3.1.38 Noise Floor Event 1997 This element is used by the WTP to notify the AC of the current noise 1998 floor at one of the WLAN interfaces exceeding the configured noise 1999 floor threshold. 2001 Element ID : 37 2003 Length : 10 octets 2005 Value : defined as follows. 2007 BSSID : 6 octets 2009 Current Channel : 2 octets 2011 Current Noise Floor : 2 octets 2013 6.1.3.1.39 Raw 802.11 Frame 2015 This element provides a generic capability for either a WTP or an AC 2016 to send a raw 802.11 frame to the other party. For example, it can 2017 be used to notify the AC of station association/disassociation events 2018 in the case of local MAC architectures. 2020 Element ID : 252 2022 Length : Variable 2024 Value : a raw 802.11 frame 2026 6.1.3.1.40 Vendor-Specific Element 2028 This element is used to transfer vendor-specific information between 2029 the WTP and the AC. 2031 Element ID : 253 2033 Length : Variable, > 3 2035 Value : This variable length element starts with a 3-octet OUI, 2036 followed by a series of octets that are specific to the vendor 2037 represented by the OUI. 2039 6.1.3.1.41 Recursion Element 2041 This element type can be used to recursively define a variable length 2042 element that should be interpreted as a series of other elements 2043 defined in this section. It can be used to bound a set of elements 2044 as a unit. 2046 Element ID : 254 2048 Length : Variable 2050 Value : A variable length element that contains a set of one or 2051 more elements defined in this section. 2053 6.1.3.1.42 Pad Element 2055 This is a generic element type which can be used to pad the packets, 2056 if necessary. 2058 Element ID : 255 2060 Length : Variable 2062 Value : A variable length element that MUST be filled with all 0s 2063 at the source and MUST be ignored at the destination. 2065 6.1.3.2 SLAPP 802.11 Control Protocol Messages 2067 6.1.3.2.1 Registration Request 2069 At the start of the SLAPP 802.11 control protocol, the WTP sends a 2070 registration request to the AC that it authenticated with. The 2071 registration request carries a list of information elements 2072 indicating the WTP's capabilities to the AC. The message starts with 2073 the SLAPP 802.11 control protocol header (Figure 8) with a SLAPP 2074 control protocol message type of 1. 2076 0 1 2 3 2077 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 2078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2079 | Maj | Min | 4 | Length | 2080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2081 | 1 | Flags | 2082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2083 | Transaction ID | 2084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2085 ~ Information Elements ~ 2086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2088 Figure 9: SLAPP 802.11 Registration Request 2090 Flags : Reserved 2092 Transaction ID : a 32-bit random number chosen by the WTP at the 2093 start of a new registration phase. This number is used in the 2094 registration response by the AC to match the response to the 2095 corresponding request. 2097 The following information elements are mandatory in the capabilities 2098 exchange. 2100 1 : CAPWAP mode 2102 2 : Number of WLAN interfaces 2104 For each WLAN interface: 2106 7 : 802.11 PHY mode and Channel Information 2108 8 : Cryptographic Capability 2110 9 : Other 802.11 standards support 2112 The following information elements may be optionally included in the 2113 registration request. 2115 For each WLAN interface: 2117 4 : WLAN Interface HW Vendor ID 2119 5 : WLAN Interface Type ID 2121 6 : Regulatory Domain 2123 10 : Antenna Information Element 2125 11 : Number of BSSIDs 2127 253 : Vendor-specific Element 2129 6.1.3.2.2 Registration Response 2131 Upon receiving a registration request, the AC may either chose to 2132 accept the WTP 2134 0 1 2 3 2135 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 2136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2137 | Maj | Min | 4 | Length | 2138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2139 | 2 | Flags | 2140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2141 | Transaction ID | 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 ~ Information Elements ~ 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 Figure 10: SLAPP 802.11 Registration Response 2148 Flags : 2150 Bit 0 : indicates the status of the transaction, 0 = successful 2151 response from the AC, 1 = the registration request is being 2152 rejected by the AC. 2154 Bits 1-7 : Reserved 2156 Bits 8-15 : If bit 0 = 1 (i.e., the registration request is 2157 being rejected by the AC), then this field contains a reason 2158 code. Otherwise, these bits are currently set to 0. The 2159 following reason codes are currently defined. 2161 0 : Reserved 2163 1 : Unspecified reason 2165 2 : Unable to handle more WTPs 2167 3 : Incompatible capabilities 2169 4-255 : Reserved 2171 Transaction ID : a 32-bit random number chosen by the WTP at the 2172 start of a new registration phase. This number is used in the 2173 registration response by the AC to match the response to the 2174 corresponding request. 2176 The following information elements are mandatory if the transaction 2177 is successful. 2179 1 : CAPWAP mode - the mode that the AC chooses from among the list 2180 of supported modes sent by the WTP in the registration request. 2182 24 : SLAPP registration ID 2184 6.1.3.2.3 De-registration Request 2186 0 1 2 3 2187 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 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | Maj | Min | 4 | Length | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | 3 | Flags | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | SLAPP Registration ID | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2195 | Reason Code | 2196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 Figure 11: SLAPP 802.11 Deregistration Request 2200 Flags : Reserved 2202 SLAPP Registration ID : The registration ID assigned by the AC 2203 upon successful registration 2205 Reason Code : The following are valid values. 2207 0 : Unspecified reason 2209 1 : The device that is the source of the frame is going down 2211 All other values are reserved 2213 6.1.3.2.4 De-registration Response 2215 The De-registration response is a simple ACK from the recipient of 2216 the corresponding de-registration request. 2218 0 1 2 3 2219 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 2220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2221 | Maj | Min | 4 | Length | 2222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 | 4 | Flags | 2224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2225 | SLAPP Registration ID | 2226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2227 | Reason Code | 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 Figure 12: SLAPP 802.11 Deregistration Response 2232 Flags : Reserved 2234 SLAPP Registration ID : The registration ID assigned by the AC 2235 upon successful registration 2237 Reason Code : The same reason code used in the corresponding 2238 request 2240 6.1.3.2.5 Configuration Request 2242 The configuration request message is used by the WTP to request a set 2243 of configuration for each BSS that the AC wishes to configure at the 2244 WTP. 2246 0 1 2 3 2247 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 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Maj | Min | 4 | Length | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2251 | 5 | Flags | 2252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2253 | SLAPP Registration ID | 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 ~ Information Element ID list ~ 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2258 Figure 13: SLAPP 802.11 Configuration Request 2260 The Information Element ID list field contains the list of IEs that 2261 the WTP is interested in obtaining configuration information for. 2263 6.1.3.2.6 Configuration Response 2265 The Configuration response message is used by the AC to respond to a 2266 configuration request by the WTP. 2268 0 1 2 3 2269 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 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Maj | Min | 4 | Length | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | 6 | Flags | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2275 | SLAPP Registration ID | 2276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 ~ Information Element list ~ 2278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2280 Figure 14: SLAPP 802.11 Configuration Response 2282 The following information elements are mandatory in the configuration 2283 response. 2285 01: CAPWAP mode 2287 For each WLAN interface: 2289 03: WLAN Interface Index 2291 27: Radio Mode 2292 07: 802.11 PHY mode and Channel Selection 2294 For each BSSID: 2296 12: BSSID Index 2298 13: ESSID 2300 08: Cryptographic Selection 2302 The following information elements may be optionally included in the 2303 configuration response. 2305 10: Antenna Information Element 2307 25: WTP Name 2309 For each WLAN interface: 2311 For each BSSID: 2313 14: ESSID Announcement Policy 2315 15: Beacon Interval 2317 16: DTIM Period 2319 17: Basic Rates 2321 18: Supported rates 2323 19: Retry Count 2325 20: Fragmentation Threshold 2327 21: RTS Threshold 2329 22: Short/Long Preamble 2331 23: 802.1Q Tag 2333 253: Vendor specific element 2335 If any of the optional IEs is absent in the configuration response 2336 message, then their default values are applied by the WTP. 2338 6.1.3.2.7 Configuration Update 2340 The Configuration Update message is initiated by the AC to push 2341 modified or updated configuration to the WTP. It has a format 2342 similar to that of the configuration response message defined above. 2344 0 1 2 3 2345 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 2346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2347 | Maj | Min | 4 | Length | 2348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2349 | 7 | Flags | 2350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2351 | SLAPP Registration ID | 2352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2353 ~ Information Element list ~ 2354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2356 Figure 15: SLAPP 802.11 Configuration Update 2358 The list of mandatory and optional IEs for the configuration update 2359 message is the same as that for the configuration response message. 2361 6.1.3.2.8 Configuration Acknowledgment 2363 The Configuration Acknowledgment message is used by the WTP to inform 2364 the AC whether it has accepted the prior configuration update or 2365 configuration response message. The WTP can reject the configuration 2366 sent by the AC, in which case it MUST return to the discovery state. 2368 0 1 2 3 2369 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 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2371 | Maj | Min | 4 | Length | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | 8 | Flags | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | SLAPP Registration ID | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2377 | Status Code | 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2380 Figure 16: SLAPP 802.11 Configuration ACK 2382 The Status Code field contains one of the following values: 2384 0 : Success - The WTP accepts that the configuration pushed by the 2385 AC and has applied it. 2387 1 : Failure - The WTP did not accept the configuration pushed by 2388 the AC and MUST be de-registered at the AC. 2390 6.1.3.2.9 Status Request 2392 The Status request message is used by the AC to request the 2393 configuration and operational status from the WTP. 2395 0 1 2 3 2396 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 2397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 | Maj | Min | 4 | Length | 2399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2400 | 9 | Flags | 2401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2402 | SLAPP Registration ID | 2403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2404 ~ Information Element ID list ~ 2405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2407 Figure 17: SLAPP 802.11 Status Request 2409 The Information Element ID list contains the list of IEs that the AC 2410 requests status for. 2412 6.1.3.2.10 Status Response 2414 The Status response message is used by the WTP to respond to a status 2415 request from the AC. 2417 0 1 2 3 2418 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 2419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2420 | Maj | Min | 4 | Length | 2421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 | 10 | Flags | 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2424 | SLAPP Registration ID | 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 ~ Information Element list ~ 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2429 Figure 18: SLAPP 802.11 Status Response 2431 The Flags field contains one of the following values: 2433 Bit 0 : If set, Unknown AC or SLAPP registration ID. If this bit 2434 is reset, then this indicates a successful response. 2436 Bit 1 : If set, WTP indicates that it has not been configured yet, 2437 otherwise the WTP is in a configured state. 2439 All other values are reserved 2441 The Status IE is mandatory in a Status Response message. 2443 6.1.3.2.11 Statistics Request 2445 The Statistics request message is used by the AC to request 2446 statistics information from the WTP. 2448 0 1 2 3 2449 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 2450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 | Maj | Min | 4 | Length | 2452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 | 11 | Flags | 2454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2455 | SLAPP Registration ID | 2456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2457 ~ Information Element list ~ 2458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 Figure 19: SLAPP 802.11 Statistics Request 2462 The Flags field contains the following bits: 2464 Bit 0 : If set to 1, then the WTP should reset the counters after 2465 sending the statistics response message. 2467 All other bits are reserved and MUST be set to 0 by the source and 2468 ignored by the destination. 2470 6.1.3.2.12 Statistics Response 2471 0 1 2 3 2472 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 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | Maj | Min | 4 | Length | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2476 | 12 | Flags | 2477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2478 | SLAPP Registration ID | 2479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2480 ~ Information Element list ~ 2481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2483 Figure 20: SLAPP 802.11 Statistics Response 2485 The Flags field contains the following bits: 2487 Bit 0 : if set then the counters have been reset as requested by 2488 the AC. 2490 Bit 1 : If set, then the WTP has encountered a statistics request 2491 from either an unknown AC or with an unknown SLAPP registration 2492 ID. 2494 Bit 2 : If set, WTP indicates that it has not been configured yet, 2495 otherwise the WTP is in a configured state. 2497 All other bits are reserved. 2499 6.1.3.2.13 Keepalive 2501 The keepalive messages can be initiated by either the WTP or the AC. 2502 It is used to probe the availability of the other party and the path 2503 between them. The initial message is termed the keepalive request, 2504 while the response to that message is termed the keepalive response. 2506 0 1 2 3 2507 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 2508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2509 | Maj | Min | 4 | Length | 2510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2511 | 13 | Flags | 2512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2513 | SLAPP Registration ID | 2514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2516 Figure 21: SLAPP Keepalive Packet 2518 The Flags field has the following values: 2520 Bit 0 : Set to 0 in a keepalive request message, set to 1 in a 2521 keepalive response message. 2523 Bit 1 : Set to 0 in a keepalive request message, set to 1 in a 2524 keepalive response message if the initiator of the keepalive 2525 request is unknown or the SLAPP registration ID is incorrect, and 2526 set to 0 otherwise. 2528 All other bits are reserved and must be set to 0 by the source and 2529 ignored at the destination. 2531 6.1.3.2.14 Key Configuration 2533 In CAPWAP mode 5, the 802.11 crypto functions are performed at the 2534 AC. So there is no need for the AC to send PTKs/GTKs to the WTP. 2535 When one of CAPWAP Modes 1-4 has been negotiated between the AC and 2536 WTP it is necessary for the AC to send both unicast and broadcast/ 2537 multicast keys to the WTP. This is accomplished after the 802.1x 2538 authenticator (which resides on the AC) has successfully 2539 authenticated the supplicant. Key configuration requests are 2540 differentiated-- unicast or broadcast-- by setting or clearing the 2541 high-order bit of the "Flags" field. The setting of this bit 2542 determine the contents of the Key configuration request following the 2543 SLAPP Registration ID. 2545 6.1.3.2.14.1 Unicast Key Configuration Request 2547 The Unicast Key Configuration Request is used by the AC to inform the 2548 WTP of the key to use when protecting unicast frames to and from a 2549 specified supplicant. 2551 0 1 2 3 2552 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 2553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2554 | Maj | Min | 4 | Length | 2555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2556 | 15 |0| Flags | 2557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2558 | SLAPP Registration ID | 2559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2560 | supplicant MAC address ~ 2561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2562 | supplicant mac address (cont) | Supp 802.1Q tag | RSVD | 2563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2564 | unicast key length | unicast key ~ 2565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 Figure 22 2569 Note the high order bit of the "Flags" field is cleared to indicate a 2570 unicast key is being sent. The 802.1Q tag field is used to indicate 2571 to the WTP which VLAN this supplicant is in and which broadcast/ 2572 multicast key to use when communicating to it with broadcast/ 2573 multicast frames. 2575 6.1.3.2.14.2 Broadcast/Multicast Key Configuration Request 2577 0 1 2 3 2578 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 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | Maj | Min | 4 | Length | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | 15 |1| Flags | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2584 | SLAPP Registration ID | 2585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2586 | 801.1q tag | RSVD | broadcast/multicast key length| 2587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2588 ~ broadcast/multicast key ~ 2589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2591 Figure 23 2593 Note the high-order bit of the "Flags" field is set indicating a 2594 broadcast/multicast key is being sent. The bits marked "RSVD" are 2595 reserved and MUST be set to zero by the AC and ignored by the WTP. 2597 6.1.3.2.14.3 Unicast Key Configuration Response 2599 The WTP acknowledges receipt of a Unicast Key Configuration Request 2600 by sending a Unicast Key Configuration Response. This response 2601 mirrors the request but does not send back the key length or the key 2602 itself. (The RSVD bits are returned for alignment purposes and MUST 2603 be set to zero by the WTP and ignored by the AC). 2605 0 1 2 3 2606 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 2607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2608 | Maj | Min | 4 | Length | 2609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2610 | 16 |0| Flags | 2611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2612 | SLAPP Registration ID | 2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 | supplicant MAC address ~ 2615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2616 | supplicant mac address (cont) | Supp 802.1Q tag | RSVD | 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2619 Figure 24 2621 6.1.3.2.14.4 Multicast Key Configuration Response 2623 The WTP acknowledges receipt of a Multicast Key Configuration Request 2624 by sending a Multicast Key Configuration Response. This response 2625 mirrors the request but does not send back the key length or the key 2626 itself. (The RSVD bits are returned for alignment purposes and MUST 2627 be set to zero by the WTP and ignored by the AC). 2629 0 1 2 3 2630 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 2631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2632 | Maj | Min | 4 | Length | 2633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 | 16 |0| Flags | 2635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2636 | SLAPP Registration ID | 2637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2638 | 801.1q tag | RSVD | 2639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 Figure 25 2643 6.1.3.3 Monitoring and Statistics 2645 An AC may want to periodically monitor the health of a WTP, collect 2646 the necessary information for diagnostics, and get notifications on 2647 pre-defined events at the WTP that may be of interest. This section 2648 defines a set of WTP statistics and events and describes the process 2649 of collecting statistics from WTPs and configuring the event 2650 notification mechanism at the WTP. It is beyond the scope of this 2651 document to describe what should/could be done with the collected 2652 information. 2654 6.1.3.3.1 Statistics Collection Procedure 2656 The simple statistics collection procedure defined here does not 2657 require the WTP to maintain any timers or any similar mechanisms. A 2658 WTP is responsible only for maintaining the statistics defined in 2659 Information Elements 29, 30, 31, and 32. The WTP must also respond 2660 to a statistics request message from the AC by delivering the 2661 appropriate statistics to the AC using a statistics response message. 2662 For example, if an AC is interested in gathering periodic statistics 2663 about some specific statistics, it is the responsibility of the AC to 2664 poll the WTP at the appropriate intervals. 2666 6.1.3.3.2 Events Procedure 2668 The event notification process includes the following: 1) Event 2669 Registration: The registration of events of interest at the WTP by 2670 the AC and 2) Notification: The communication of event-related 2671 information by the WTP to AC whenever the conditions for a specific 2672 registered event has occurred. The set of events supported by a WTP 2673 and the event-specific parameters that may be configured as part of a 2674 event registration are given in Section 6.1.3.3.3. 2676 6.1.3.3.3 WTP Events 2678 This section defines a set of WTP events along with the event- 2679 specific parameters that may be configured by ACs and the event- 2680 related information that should be delivered to the ACs by WTPs when 2681 the conditions for a particular configured event has occurred. 2683 Radar Detection Event: Configure whether the AC is interested in 2684 receiving a notification whenever a radar event is detected. The 2685 WTP may notify the AC about the type of radar interference and the 2686 new channel that the WTP has moved to as a result, if any, using 2687 the Radar Detection Event Element (element ID : 35). 2689 Excessive Retry Event: Configure the number of consecutive 2690 transmission failures before a notification is generated. The WTP 2691 may notify the MAC address of the STA and the number of 2692 consecutive unacknowledged frames so far using the Excessive Retry 2693 Event Element (element ID : 36). 2695 Noise Floor Event: Configure the noise floor threshold above which 2696 an event notification would be generated by the WTP. The WTP may 2697 notify the AC with the most recent measured noise floor that 2698 exceeded the configured threshold using the Noise Floor Event 2699 Element (element ID : 37). 2701 De-authentication Event: Configure whether the AC is interested in 2702 receiving a notification whenever a station has been de- 2703 authenticated by WTP. The WTP may notify the AC with the MAC 2704 address of the STA along with a reason code (inactivity, etc). 2706 Association Event: Needed in local MAC architecture 2708 Disassociation Event: Needed in local MAC architecture 2710 6.1.4 Protocol Operation 2712 The SLAPP 802.11 control protocol operation is described in this 2713 section. 2715 6.1.4.1 SLAPP 802.11 Control Protocol State Machine 2717 6.1.4.1.1 At the WTP 2719 +-------------+ 2720 | discovering |<-------------------------------+<----+ 2721 +-------------+ | | 2722 ^ ^ | | 2723 | | +-----------+ | | 2724 | | | securing | | | 2725 | | +----+------+ | | 2726 | | | | | 2727 | | v | | 2728 | | +--------------+ | | 2729 | | +--->| Unregistered | | | 2730 | | | +------+-------+ | | 2731 | | | | | | 2732 | | | |Registration | | 2733 | | |Timeout |Request | | 2734 | | | | | | 2735 | | | v | | 2736 | | | +--------------+ | | 2737 | | +----+ Registration | | | 2738 | | | | | | 2739 | | Reject | | | | 2740 | +--------+ Pending | | | 2741 | nTimeout>3| | | | 2742 | | | | | 2743 | +------+-------+ | | 2744 | | | | 2745 | |Accept | | 2746 | | | | 2747 | | | | 2748 | v | | 2749 | +------+-------+ | | 2750 | | Registered | | | 2751 | +--->| | | | 2752 | | +------+-------+ | | 2753 | | | | | 2754 | |Timeout |Config | | 2755 | | |Request | | 2756 | | | | | 2757 | | v | | 2758 | | +------+-------+ | | 2759 | +----+ | Reject| | 2760 | |Configuration | | | 2761 | Reject | Pending | | | 2762 +-----------+ | | | 2763 ^ nTimeout>3+------+-------+ | | 2764 | | | | 2765 | | | | 2766 De-reg| | +----------------+ | | 2767 resp | | v Accept | | | 2768 +----+---+ +------+----+--+ +-+---+--+ | 2769 | | De-reg| | | Update | | 2770 | De +<------+ Configured +-----------+ | | 2771 |Register| req | | | Pending| | 2772 | | | | +----+---+ | 2773 +--------+ +------+-------+ | 2774 | | 2775 | | 2776 | | 2777 Too |Many | 2778 Keepalive | 2779 Failures | 2780 | | 2781 | | 2782 | Deregister | 2783 +-------------------------------+ 2785 In Configured and/or Registered states, respond to 2786 Status Requests, Statistics Requests, Keepalives, Key Config 2788 Figure 26: SLAPP 802.11 Control Protocol at the WTP 2790 6.1.4.1.1.1 State Machine Explanation 2792 Unregistered : The transition into this state is from the securing 2793 state (Figure 3). Send registration request message to move to 2794 Registration Pending state, set timer for registration response. 2796 Registration Pending : On a registration response from AC, cancel 2797 registration timer. If response is successful, move to Registered 2798 state. If not, move to discovering state (Figure 3). If timer 2799 expires, if nTimeout >3, then move to discovering state. If not, 2800 return to Unregistered state. 2802 Registered : Send Configuration request message to AC to move to 2803 Configuration Pending state, and set timer for configuration 2804 response. In this state, respond to status request, statistics 2805 request, and keepalive messages from AC. 2807 Configuration Pending : If configuration response received from AC, 2808 cancel configuration response timer. If response is successful 2809 and the configuration is acceptable, then send Configuration ACK 2810 message to AC, and move to Configured state. If configuration 2811 request is rejected or configuration is not acceptable, then send 2812 a deregister request to AC and move to discovering. If 2813 configuration response timer expires, move to Registered state 2814 unless nTimeout >3, in which case move to discovering state. 2816 Configured : In the Configured state, the WTP responds to Status 2817 request, Statistics Request, and Keepalive messages from the AC. 2818 If it receives a de-register request message from the AC, then it 2819 sends a de-register response to the AC and moves to the 2820 discovering state. If the WTP receives a Configuration Update 2821 message, then it moves to the Update Pending state. If it 2822 receives too many consecutive Keepalive failures (no responses 2823 from the AC to Keepalive requests), then it sends a deregister 2824 message to the AC and moves to the discovering state. 2826 Update Pending : In the Update Pending state, the WTP analyzes the 2827 configuration information received in the Configuration Update 2828 message. If the configuration is found to be acceptable, then it 2829 applies the configuration and returns to the Configured state. If 2830 the WTP chooses to reject the configuration update, then it sends 2831 a deregister request to the AC and moves to the discovering state. 2833 De-register : From the Configured state, the WTP moves to the De- 2834 register state when it receives a deregister request message from 2835 the AC. It sends a deregister response to the AC and moves to the 2836 discovering state. 2838 6.1.4.1.2 At the AC 2840 +----------+ 2841 | securing | 2842 +----+-----+ 2843 | 2844 | 2845 | 2846 v 2847 +--------------+ 2848 +--------| Unregistered | 2849 | +----+---------+ 2850 | | 2851 |Timeout |Register 2852 | |request 2853 | v +-------------+ 2854 | +----------+ Accept | Registration| 2855 | +---+Register +----------->| Pending | 2856 | | |Processing| +-+-----+-----+ 2857 | | +----------+ | | 2858 | | | | 2859 | |Reject Timeout | 2860 | | | |Config 2861 | | | |Request 2862 | | +--------------+ | | 2863 | +----->| |<------+ | 2864 | | discovering | v 2865 +----------->| | +------------+ 2866 +--------------+ | Registered | 2867 ^ ^ ^ +----+-------+ 2868 | | | | 2869 | | | |Config 2870 | | | |Response 2871 | | | v 2872 | | | Timeout +------------+ 2873 | | +----------| Config | 2874 | | or Reject | Pending | 2875 | | +----+-------+ 2876 | | | 2877 | | |Config ACK 2878 | | v 2879 | | Deregister +------------+ 2880 | +-------------| | 2881 | or Keepalive | Configured |<--+ 2882 | failures | | | 2883 | +----+-------+ | 2884 Reject| | | 2885 or| | | 2886 Timeout +-----------+ |Config | 2887 | | Update | |Update | 2888 +-----| Pending |<-----+ | 2889 +----+------+ | 2890 | Accept | 2891 +-------------------------+ 2893 Figure 27: SLAPP 802.11 Control Protocol at the AC 2895 6.1.4.1.2.1 State Machine Explanation 2897 The states "securing" and "discovering" are described in Figure 3. 2899 Unregistered : This state is entered from the securing state 2900 described in Figure 3. In this state, the AC is waiting for a 2901 registration request message from the WTP. Upon receiving the 2902 registration request message, it moves into the Registration 2903 Processing state. 2905 Registration Processing : In this state, the AC must determine if it 2906 can accept the new WTP or not. If the AC decides to accept the 2907 WTP, it must pick a CAPWAP mode to operate in and send a 2908 registration response message with a success code and moves to the 2909 Registration Pending state. If the AC chooses to reject the 2910 current registration request from the WTP, it must send a 2911 registration response with a failure code and move to the 2912 discovering state. 2914 Registration Pending : If the timer expires before a response from 2915 the WTP is received, then the AC destroys the registration state 2916 and moves to the discovering state. If a configuration request 2917 message is received from the WTP, then the AC moves into the 2918 Registered state and processes the configuration request message. 2919 It sends a configuration response message to the WTP with the 2920 appropriate IEs and moves into the Configuration Pending state. 2922 Configuration Pending : If the timer expires before a response is 2923 received from the WTP, then the AC destroys the current 2924 registration and moves into the discovering state. If a 2925 configuration ACK is received from the WTP, but contains a failure 2926 code, then the AC again destroys the registration state and moves 2927 into the discovering state. If the configuration ACK from the WTP 2928 is successful, then the AC moves to the Configured state. 2930 Configured : In the Configured state, the AC can send status request, 2931 statistics request, keepalive, key configuration messages to the 2932 WTP. Any response to these messages from the WTP that indicates 2933 an unknown SLAPP registration ID or an unknown AC causes the AC to 2934 destroy any registration or configuration state and move to the 2935 discovering state. From the configured state, the AC can send a 2936 configuration update message and move into the Update Pending 2937 state. If it receives a deregister request from the WTP then it 2938 destroys all current registration and configuration state and 2939 moves into the discovering state. If a number of successive 2940 keepalive messages go unacknowledged by the WTP, then the AC moves 2941 into the discovering state. 2943 Update Pending : When the AC receives an configuration ACK message 2944 with a success code, then it returns to the Configured state. If 2945 the status code is a failure or if the timer expires before the 2946 configuration ACK is received from the WTP, the AC destroys all 2947 registaration and configuration state for the WTP and moves into 2948 the discovering state. 2950 6.2 Image Download Protocol 2952 The Image Download protocol is a control protocol defined in this 2953 draft that is generic enough to be agnostic to the underlying 2954 technology. 2956 In the image download protocol, the WTP obtains a bootable image from 2957 the AC by receiving a series of image transfer packets. Missed image 2958 data packets are re-requested by the WTP by sending image data 2959 request packets indicating the missing packets. 2961 The image to download is divided into slices of equal size (except 2962 for the last slice which can be less than the slice size provided it 2963 is also greater than zero). The size of each slice depends on the 2964 MTU determined by the DTLS exchange and SHOULD be the realized MTU 2965 minus the size of an Image Download Request (Figure 29). 2967 Note that the image download packet and download image request is 2968 encapsulated in a DTLS header which secures the image download. 2970 6.2.1 Image Download Packet 2972 The format of an image download packet is shown in Figure 28. 2974 0 1 2 3 2975 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 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2977 | Maj | Min | Type = 3 | Length | 2978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2979 | RESERVED |M|R| packet sequence number | 2980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2981 ~ image data slice ~ 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2984 Figure 28: SLAPP Image Download Packet 2986 where: 2988 length: variable 2990 RESERVED: unused in this version of SLAPP, MUST be zero (0) on 2991 transmission and ignored upon receipt 2993 M: the "More" bit indicating that the current packet is not the final 2994 one 2996 R: the "Request" bit. This bit MUST be set to one (1) when the 2997 packet is the response to a request and zero (0) otherwise. 2999 packet sequence number: a monotonically increasing counter which 3000 assigns a unique number to each slice of the image 3002 image data slice: a portion of the bootable image. 3004 6.2.2 Image Download Request 3006 The format of an image download request is show in Figure 29. 3008 0 1 2 3 3009 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 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3011 | Maj | Min | Type = 3 | Length | 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | RESERVED |M|R| packet sequence number | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 Figure 29: SLAPP Image Download Request Packet 3018 where: 3020 length: eight (8) octets 3022 RESERVED: unused in this version of SLAPP, MUST be zero on 3023 transmission and ignored upon receipt 3025 M: the "More" bit. This MUST be equal to the one (1) when negatively 3026 acknowledging a missed packet and set to zero (0) when indicating 3027 the end of the Image Download protocol. 3029 R: the "Request" bit. This MUST be one in an Image Download Request. 3031 packet sequence number: the packet sequence number of the missing 3032 image data slice. 3034 6.2.3 Image Download Process 3036 The AC will divides the bootable image into a series of slices and 3037 sends each slice as an Image Download packet. The size of each image 3038 data slice (and therefore the size of each image download packet) 3039 depends on the MTU of the connection determined during the DTLS 3040 handshake. With the transmission of each slice the AC MUST increment 3041 the packet sequence number. 3043 Image Download packets are negatively ack'd. An AC MUST NOT assume 3044 anything about the reception of packets it sends based upon negative 3045 acks. One could naively assume that since the packets are sent 3046 sequentially that all packets with a sequence number of "n - 1" are 3047 implicitly ack'd by the receipt of a request for the packet with 3048 sequence number "n" to be retransmitted. Such an assumption would be 3049 incorrect since previous requests could, themselves, have been 3050 dropped. 3052 The image download process is initiated by the WTP requesting a 3053 packet with the packet sequence number of zero (0). The AC sets the 3054 packet sequence counter for this WTP to one (1) and sends the first 3055 slice. The "Request" bit for the first slice sent by the AC MUST be 3056 set to zero (0) since the first slice was technically not requested. 3058 The WTP sets a periodic timer that, when it fires, causes the WTP to 3059 sends Image Download requests for slices that have been missed since 3060 the last periodic timer had fired. Since individual Image Download 3061 packets are not ack'd the AC MUST NOT set a timer when each one is 3062 sent. 3064 If a WTP notices missed image transfer packets-- when the difference 3065 between the packet sequence number of a received image transfer 3066 packet and the packet sequence number of the last image transfer 3067 packet previously received is greater than one-- it will note that 3068 fact in a bitmask. When the periodic timer fires the WTP will 3069 request the slices that are absent from that bitmask. Each slice 3070 will be requested by sending a Download Request with a length of 3071 eight (8) and indicating the sequence number of the packet requested. 3072 The AC MUST interleave these retransmissions with packets in the 3073 sequence. 3075 Since both sides implicitly agree upon the MTU of the link the WTP 3076 will know the slice size that the AC will use during the Image 3077 Download process. A dropped packet will therefore result in an 3078 internal buffer pointer on the WTP being incremented by the slice 3079 size and the lost packet requested. When the lost packet is received 3080 it can be inserted into the buffer in the space provided by the 3081 pointer increment when its loss was first detected. That is, loss of 3082 packet will result in packet being re-requested and when 3083 received inserted into the buffer at an offset of * 3084 from the start of the buffer. 3086 The final packet sent by the AC will not have the "more" bit set and 3087 this indicates to the WTP that the end of the image has been 3088 received. This final packet is acknowledged by the WTP indicating 3089 the end of the Image Download process. 3091 A lost final packet will result in the AC resending the final packet 3092 again (see Section 4.4). 3094 6.2.4 Image Download State Machine 3096 The Image Download protocol is a negotiated control protocol defined 3097 for SLAPP. Transitions to it come from the "secure" state and 3098 transitions out of it go to "acquire". See Figure 3. 3100 6.2.4.1 AC 3102 The AC's state machine for the Image Download protocol is shown in 3103 Figure 30. The AC maintains the following variables for its state 3104 machine: 3106 seq_num: the current slice that is being sent 3108 nslices: the total number of slices in the image 3109 req_num: the number of the slice that was requested 3111 more: whether the "More bit" in the packet should be set 3113 starved: a timer which sets the maximum amount of time in which an AC 3114 will attempt to download an image. 3116 Note: the symbol "C" indicates an event in a state which results in 3117 the state remaining the same. 3119 | 3120 v 3121 +----------+ 3122 | waiting | 3123 +----------+ 3124 | 3125 | seq_num = 1, more = 1, 3126 | nslices = x, starved = t 3127 M bit v 3128 +----------+ is 0 +-------------+ 3129 | finished |<-------| received |<------\ 3130 +----------+ | |<----\ | 3131 +-------------+ | | 3132 req_num = requested | | | 3133 packet | M bit is 1 | | 3134 V | | 3135 +----------+ | | 3136 seq_num++, C| sending |------/ | 3137 req_num=0 +----------+ | 3138 | | 3139 | | | 3140 +-------------+ | | | 3141 | discovering |<----/ | | 3142 | |<----\ | | 3143 +-------------+ | | | 3144 | v v 3145 +--------+ | 3146 | idle |---------/ 3147 +--------+ 3149 Figure 30: SLAPP Image Download Protocol State Machine at the AC 3151 The following states are defined: 3153 Waiting: When the AC leaves the SLAPP state of "Secure" it enters the 3154 "Waiting" state of the Image Download protocol. seq_num is set to 3155 one (1), more is set to one (1), and nslices is set to the number 3156 of slices in the particular image to download, and starved is set 3157 to the maximum amount of time the AC will devote to downloading a 3158 particular image. 3160 Received: The AC enters this state when it has received an Image 3161 Download request. If the sequence number of the packet is zero 3162 (0) it sets seq_num to one (1) and transitions to Sending, else if 3163 the M bit is set it sets req_num to the sequence number of the 3164 request and transitions to Sending else (if the M bit is clear) it 3165 transitions to Finished. 3167 Sending: The AC is sending a slice to the WTP. If req_num is equal 3168 to zero (0) it sends the slice indicated by seq_num and increments 3169 seq_num. If req_num is greater than zero (0) it sends the slice 3170 indicated by req_num and sets req_num to zero (0). The "More" bit 3171 in either case is set depending on the value of more. As long as 3172 no request packets are received Sending transitions to Sending. 3173 When seq_num equals nslices "More" is set to zero (0) and the 3174 state transitions to Idle. If the starved timer expires the AC 3175 transitions to the SLAPP state of Discovering. 3177 Idle: The AC has sent all the slices in the image and is just waiting 3178 for requests. If the starved timer expires the AC transitions to 3179 the SLAPP state of Discovering. 3181 Finished: The Image Download protocol has terminated. The starved 3182 timer is canceled. 3184 6.2.4.2 WTP 3186 The WTP's state machine for the Image Download protocol is shown in 3187 Figure 31. The WTP maintains the following variables for its state 3188 machine: 3190 recv_num: the sequence number of the last received slice 3192 req: a bitmask whose length equals the number of slices in the image 3194 retry: a timer 3196 giveup: a timer 3198 final: the sequence number of the last slice 3200 Note: the symbol "C" indicates an event in a state which results in 3201 the state remaining the same. 3203 | 3204 v 3205 +----------+ 3206 | init | recv_num = 0, 3207 +----------+ final = 0, req = 0, 3208 | giveup = t 3209 v 3210 +----------+ +-----------+ 3211 | finished |<------- | sending |<-------\ 3212 +----------+ +-----------+ | 3213 | | retry fires 3214 v | 3215 +--------------+ | 3216 bit in req = C| receiving |------/ 3217 seq_num in packet +--------------+ 3218 is set | 3219 | giveup fires 3220 v 3221 +-------------+ 3222 | discovering | 3223 +-------------+ 3225 Figure 31: SLAPP Image Download Protocol State Machine at the WTP 3227 The following states are defined: 3229 Init: 3231 When the WTP leaves the SLAPP state of "Secure" it enters the 3232 "Init" state of the Image Download Protocol. recv_num, final, and 3233 the req bitmask are set to zero (0), and the giveup timer is set 3234 to a suitably large number. The WTP transitions directly to 3235 Sending. 3237 Sending: 3239 If recv_num is zero (0) the WTP sends a request for a packet with 3240 sequence number of zero (0) and the "More" bit set to one (1). 3241 Otherwise for every unset bit in req between one (1) and recv_num 3242 a request packet is sent with the sequence number corresponding to 3243 the unset bit in req and the "More" bit set to more. 3245 If there are no unset bits in req and final is non-zero a request 3246 packet is sent for the sequence number represented by final with 3247 the "More" bit cleared, giveup is cleared and the state machine 3248 transitions to Finished. Otherwise retry is set to a suitable 3249 value and the WTP transitions to Receiving. 3251 Receiving: 3253 In this state the WTP receives Image Download packets. The bit in 3254 req corresponding to the sequence number in the received packet 3255 is set indicating this packet has been received. If the sequence 3256 number of the received packet has already been received the packet 3257 is silently dropped, otherwise the data in the packet is stored as 3258 the indicated slice in a file which represents the downloaded 3259 image. If the received packet has the "More" bit cleared final is 3260 set to the sequence number in that packet. When the retry timer 3261 fires the WTP transitions to Sending. If the giveup timer fires 3262 the WTP transitions to the SLAPP state of Discovering. 3264 Finished: 3266 The image download protocol has finished. 3268 7. Security Considerations 3270 This document describes a protocol, SLAPP, which uses a different 3271 protocol, DTLS, to provide for authentication, key exchange, and bulk 3272 data encryption of a negotiated control protocol. It's security 3273 considerations are therefore those of DTLS. 3275 The AC creates state upon receipt of an acceptable Discovery Request. 3276 AC implementations of SLAPP SHOULD therefore take measures to protect 3277 themselves from denial of service attacks which attempt to exhaust 3278 resources on target machines. These measures could take the form of 3279 randomly dropping connections when the number of open connections 3280 reaches a certain threshold. 3282 The WTP exposes information about itself during the discovery phase. 3283 Some of this information could not be gleaned by other means. 3285 8. Extensibility to other technologies 3287 The SLAPP protocol can be considered to be a technology-independent 3288 protocol that can be extended with technology-specific components to 3289 solve an interoperability problem where a central controller from one 3290 vendor is expected to control and manage network elements from a 3291 different vendor. 3293 While the description of the SLAPP protocol in this draft assumes 3294 that it is meant to solve the multi-vendor interoperability problem 3295 as defined in the CAPWAP problem statement [3], splitting the 3296 solution to two components where technology-dependent control 3297 protocols are negotiated using a technology-independent framework 3298 enables the use of SLAPP as the common framework for multiple 3299 underlying technologies that are vastly different from one another. 3301 9. References 3303 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3304 Levels", March 1997, . 3306 [2] "Architecture Taxonomy for Control and Provisioning of Wireless 3307 Access Points(CAPWAP)", August 2004, . 3310 [3] "Configuration and Provisioning for Wireless Access Points 3311 (CAPWAP) Problem Statement", February 2005, 3312 . 3314 [4] "Generic Routing Encapsulation", March 2000, 3315 . 3317 [5] "Requirements for Internet Hosts - Communication Layers", 3318 October 1989, . 3320 [6] Govindan, S., "Objectives for Control and Provisioning of 3321 Wireless Access Points (CAPWAP)", November 2004, . 3325 [7] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3326 Security", February 2004, . 3329 [8] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 3330 RFC 2246, January 1999, 3331 . 3333 [9] Modadugu, N. and E. Rescorla, "The Design and Implementation of 3334 Datagram TLS", 3335 . 3337 [10] Krishna, P. and D. Husak, "Simple Lightweight RFID Reader 3338 Protocol", March 2005, . 3341 Authors' Addresses 3343 Partha Narasimhan 3344 Aruba Networks 3345 1322 Crossman Ave 3346 Sunnyvale, CA 94089 3348 Phone: +1 408-480-4716 3349 Email: partha@arubanetworks.com 3351 Dan Harkins 3352 Trapeze Networks 3353 5753 W. Las Positas Blvd 3354 Pleasanton, CA 94588 3356 Phone: +1-925-474-2212 3357 Email: dharkins@trpz.com 3359 Subbu Ponnuswamy 3360 Aruba Networks 3361 1322 Crossman Ave 3362 Sunnyvale, CA 94089 3364 Phone: +1 408-754-1213 3365 Email: subbu@arubanetworks.com 3367 Intellectual Property Statement 3369 The IETF takes no position regarding the validity or scope of any 3370 Intellectual Property Rights or other rights that might be claimed to 3371 pertain to the implementation or use of the technology described in 3372 this document or the extent to which any license under such rights 3373 might or might not be available; nor does it represent that it has 3374 made any independent effort to identify any such rights. Information 3375 on the procedures with respect to rights in RFC documents can be 3376 found in BCP 78 and BCP 79. 3378 Copies of IPR disclosures made to the IETF Secretariat and any 3379 assurances of licenses to be made available, or the result of an 3380 attempt made to obtain a general license or permission for the use of 3381 such proprietary rights by implementers or users of this 3382 specification can be obtained from the IETF on-line IPR repository at 3383 http://www.ietf.org/ipr. 3385 The IETF invites any interested party to bring to its attention any 3386 copyrights, patents or patent applications, or other proprietary 3387 rights that may cover technology that may be required to implement 3388 this standard. Please address the information to the IETF at 3389 ietf-ipr@ietf.org. 3391 Disclaimer of Validity 3393 This document and the information contained herein are provided on an 3394 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3395 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3396 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3397 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3398 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3399 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3401 Copyright Statement 3403 Copyright (C) The Internet Society (2005). This document is subject 3404 to the rights, licenses and restrictions contained in BCP 78, and 3405 except as set forth therein, the authors retain all their rights. 3407 Acknowledgment 3409 Funding for the RFC Editor function is currently provided by the 3410 Internet Society.