idnits 2.17.1 draft-ietf-opsawg-capwap-hybridmac-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 16, 2014) is 3572 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Shao 3 Internet-Draft H. Deng 4 Intended status: Standards Track China Mobile 5 Expires: January 17, 2015 R. Pazhyannur 6 Cisco Systems 7 F. Bari 8 AT&T 9 R. Zhang 10 China Telecom 11 S. Matsushima 12 SoftBank Telecom 13 July 16, 2014 15 IEEE 802.11 MAC Profile for CAPWAP 16 draft-ietf-opsawg-capwap-hybridmac-05 18 Abstract 20 The CAPWAP protocol defines two entities: a Wireless Transmission 21 Point (WTP) and an Access Controller (AC). The CAPWAP protocol 22 binding for IEEE 802.11 defines two MAC (Medium Access Control) modes 23 for IEEE 802.11 WTP: Split and Local MAC, and describes the required 24 functionality split between the WTP and AC for each mode. However, 25 in the split MAC mode, the partitioning of encryption/decryption 26 functions are not been clearly clearly defined. In the Split MAC 27 mode description, IEEE 802.11 encryption is specified as located in 28 either at the AC or the WTP, with no clear way for the AC to inform 29 the WTP of where the encryption functionality should be located. 30 This lack of specification leads to interoperability issues, 31 especially when the AC and WTP come from different vendors. To 32 prevent interoperability issues, this specification defines an IEEE 33 802.11 MAC profile message element in which each profile specifies an 34 unambiguous division of encryption functionality between the WTP and 35 AC. The IEEE 802.11 MAC profile is used as follows: the WTP informs 36 the AC of the supported profiles during the discovery or join process 37 and the AC configures the WTP with one of the supported profiles when 38 configuring the WLAN. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on January 17, 2015. 57 Copyright Notice 59 Copyright (c) 2014 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 75 2. Conventions used in this document . . . . . . . . . . . . . . 4 76 3. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 5 77 3.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 5 78 3.2. Split MAC with AC encryption . . . . . . . . . . . . . . 6 79 3.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 7 80 4. MAC Profile Message Element Definitions . . . . . . . . . . . 8 81 4.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 8 82 4.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 9 83 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 87 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 The CAPWAP protocol supports two MAC modes of operation: Split and 93 Local MAC, as described in [RFC5415], [RFC5416]. However, there are 94 MAC functions that have not been clearly defined. For example IEEE 95 802.11 encryption is specified as located in either in the AC or the 96 WTP with no clear way to negotiate where it should be located. 97 Because different vendors have different definitions of the MAC mode, 98 many MAC layer functions are mapped differently to either the WTP or 99 the AC by different vendors. Therefore, depending upon the vendor, 100 the operators in their deployments have to perform different 101 configurations based on implementation of the two modes by their 102 vendor. If there is no clear specification, then operators will 103 experience interoperability issues with WTPs and ACs from different 104 vendors." 106 Figure 1 from [RFC5416], illustrates how some functions are processed 107 in different places in the Local MAC and Split MAC mode. 108 Specifically, note that in the Split MAC mode the IEEE 802.11 109 encryption/decryption is specified as WTP/AC implying that it could 110 be at either location. 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | Functions | Local MAC | Split MAC | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | |Distribution Service | WTP/AC | AC | 116 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | |Integration Service | WTP | AC | 118 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 | |Beacon Generation | WTP | WTP | 120 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | |Probe Response Generation| WTP | WTP | 122 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Function |Power Mgmt | WTP | WTP | 124 + |/Packet Buffering | | | 125 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | |Fragmentation | WTP | WTP/AC | 127 + |/Defragmentation | | | 128 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | |Assoc/Disassoc/Reassoc | WTP/AC | AC | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 | |Classifying | WTP | AC | 132 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | 802.11 QoS |Scheduling | WTP | WTP/AC | 134 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | |Queuing | WTP | WTP | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | |IEEE 802.1X/EAP | AC | AC | 138 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | 802.11 RSN |RSNA Key Management | AC | AC | 140 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | |IEEE 802.11 | WTP | WTP/AC | 142 + |Encryption/Decryption | | | 143 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1: Functions in Local MAC and Split MAC 147 To solve this problem, this specification introduces IEEE 802.11 MAC 148 profile. The MAC profile unambiguously specifies where the various 149 MAC functionality should be located. 151 2. Conventions used in this document 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 3. IEEE MAC Profile Descriptions 159 A IEEE MAC Profile refers to a description of how the MAC 160 functionality is split between the WTP and AC shown in Figure 1. 162 3.1. Split MAC with WTP encryption 164 The functional split for the Split MAC with WTP encryption is 165 provided in Figure 2. This profile is similar to the Split MAC 166 description in [RFC5416], except that IEEE 802.11 encryption/ 167 decryption is at the WTP. Note that fragmentation is always done at 168 the same entity as the encryption. Consequently, in this profile 169 fragmentation/defragmentation is also done only at the WTP. Note 170 that scheduling functionality is denoted as WTP/AC. As explained in 171 [RFC5416], this means that the admission control component of IEEE 172 802.11 resides on the AC, the real-time scheduling and queuing 173 functions are on the WTP. 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Functions | Profile | 177 | | 0 | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | |Distribution Service | AC | 180 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | |Integration Service | AC | 182 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | |Beacon Generation | WTP | 184 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | |Probe Response Generation| WTP | 186 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Function |Power Mgmt | WTP | 188 + |/Packet Buffering | | 189 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | |Fragmentation | WTP | 191 + |/Defragmentation | | 192 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | |Assoc/Disassoc/Reassoc | AC | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | |Classifying | AC | 196 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | 802.11 QoS |Scheduling | WTP/AC | 198 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | |Queuing | WTP | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | |IEEE 802.1X/EAP | AC | 202 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | 802.11 RSN |RSNA Key Management | AC | 204 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | |IEEE 802.11 | WTP | 206 + |Encryption/Decryption | | 207 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Functions in Split MAC with WTP Encryption 211 3.2. Split MAC with AC encryption 213 The functional split for the Split MAC with AC encryption is provided 214 in Figure 3. This profile is similar to the Split MAC in [RFC5416] 215 except that IEEE 802.11 encryption/decryption is at the AC. Since 216 fragmentation is always done at the same entity as the encryption, in 217 this profile, AC does fragmentation/defragmentation. 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Functions | Profile | 221 | | 1 | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | |Distribution Service | AC | 224 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | |Integration Service | AC | 226 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | |Beacon Generation | WTP | 228 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | |Probe Response Generation| WTP | 230 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Function |Power Mgmt | WTP | 232 + |/Packet Buffering | | 233 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | |Fragmentation | AC | 235 + |/Defragmentation | | 236 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | |Assoc/Disassoc/Reassoc | AC | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | |Classifying | AC | 240 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | 802.11 QoS |Scheduling | WTP | 242 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | |Queuing | WTP | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | |IEEE 802.1X/EAP | AC | 246 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | 802.11 RSN |RSNA Key Management | AC | 248 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | |IEEE 802.11 | AC | 250 + |Encryption/Decryption | | 251 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3: Functions in Split MAC with AC encryption 255 3.3. IEEE 802.11 MAC Profile Frame Exchange 257 An example of message exchange using the IEEE 802.11 MAC Profile 258 message element is shown in Figure 4. The WTP informs the AC of the 259 various MAC profiles it supports. This happens either in a Discovery 260 Request message or the Join Request message. The AC determines the 261 appropriate profile and configures the WTP with the profile while 262 configuring the WLAN. 264 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 265 | WTP | | AC | 266 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 267 |Join Request[Supported IEEE 802.11 | 268 | MAC Profiles ] | 269 |---------------------------------------->| 270 | | 271 |Join Response | 272 |<----------------------------------------| 273 | | 274 |IEEE 802.11 WLAN Config. Request [ | 275 | IEEE 802.11 Add WLAN, | 276 | IEEE 802.11 MAC Profile | 277 | ] | 278 |<----------------------------------------| 279 | | 280 |IEEE 802.11 WLAN Config. Response | 281 |---------------------------------------->| 283 Figure 4: Message Exchange For Negotiating MAC Profile 285 4. MAC Profile Message Element Definitions 287 4.1. IEEE 802.11 Supported MAC Profiles 289 The IEEE 802.11 Supported MAC Profile message element allows the WTP 290 to communicate the profiles it supports. The Discovery Request 291 message, Primary Discovery Request message, and Join Request message 292 may include one such message element. 294 0 1 2 3 295 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 296 +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 297 | Num_Profiles | Profile_1 | Profile_[2..N].. 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 300 Figure 5: IEEE 802.11 Supported MAC Profiles 302 o Type: TBD for IEEE 802.11 Supported MAC Profiles 303 o Num_Profiles >=1: This refers to number of profiles present in 304 this message element. There must be at least one profile. 305 o Profile: Each profile is idnentified by a value specified in 306 Section 4.2. 308 4.2. IEEE 802.11 MAC Profile 310 The IEEE 802.11 MAC Profile message element allows the AC to select a 311 profile. This message element may be provided along with the IEEE 312 802.11 ADD WLAN message element while configuring a WLAN on the WTP. 314 0 1 2 3 4 5 6 7 315 +=+-+-+-+-+-+-+-+ 316 | Profile | 317 +-+-+-+-+-+-+-+-+ 319 Figure 6: IEEE 802.11 MAC Profile 321 o Type: TBD for IEEE 802.11 MAC Profile 322 o Profile: The profile is identified by a value as given below 324 * 0: This refers to the Split MAC Profile with WTP encryption 325 * 1: This refers to the Split MAC Profile with AC encryption 327 5. Security Considerations 329 This document does not introduce any new security risks compared to 330 [RFC5416]. The security considerations described in [RFC5416] apply 331 here as well. 333 6. IANA Considerations 335 This document requires the following IANA actions: 337 o This specification defines two new message elements, IEEE 802.11 338 Supported MAC Profiles (described in Section 4.1) and IEEE 802.11 339 MAC Profile (described in Section 4.2). These elements needs to 340 be registered in the existing CAPWAP Message Element Type 341 registry, defined in [RFC5415]. The values for these elements 342 needs to be between 1024 and 2047 (see Section 15.7 in [RFC5415]). 344 CAPWAP Protocol Message Element Type Value 345 IEEE 802.11 Supported MAC Profiles TBD1 346 IEEE 802.11 MAC Profile TBD2 347 o The IEEE 802.11 Supported MAC Profiles message element and IEEE 348 802.11 MAC Profile message element include a Profile Field (as 349 defined in Section 4.2). The Profile field in the IEEE 802.11 350 Supported MAC Profiles denotes the MAC profiles supported by the 351 WTP. The profile field in the IEEE MAC profile denotes MAC 352 profile assigned to the WTP. The namespace for the field is 8 353 bits (0-255). This specification defines two values, zero (0) and 354 one (1) as described below. The remaining values (2-255) are 355 controlled and maintained by IANA and require an Expert Review. 356 IANA needs to create a registry whose format is given below. 358 Profile Type Value Reference 359 Split MAC with WTP encryption 0 360 Split MAC with AC encryption 1 362 7. Contributors 364 Yifan Chen chenyifan@chinamobile.com 366 Naibao Zhou zhounaibao@chinamobile.com 368 8. Acknowledgments 370 The authors are grateful for extremely valuable suggestions from 371 Dorothy Stanley in developing this specification. 373 Guidance from management team: Melinda Shore, Scott Bradner, Chris 374 Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly 375 appreciated. 377 9. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 383 Provisioning of Wireless Access Points (CAPWAP) Protocol 384 Specification", RFC 5415, March 2009. 386 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 387 Provisioning of Wireless Access Points (CAPWAP) Protocol 388 Binding for IEEE 802.11", RFC 5416, March 2009. 390 Authors' Addresses 392 Chunju Shao 393 China Mobile 394 No.32 Xuanwumen West Street 395 Beijing 100053 396 China 398 Email: shaochunju@chinamobile.com 399 Hui Deng 400 China Mobile 401 No.32 Xuanwumen West Street 402 Beijing 100053 403 China 405 Email: denghui@chinamobile.com 407 Rajesh S. Pazhyannur 408 Cisco Systems 409 170 West Tasman Drive 410 San Jose, CA 95134 411 USA 413 Email: rpazhyan@cisco.com 415 Farooq Bari 416 AT&T 417 7277 164th Ave NE 418 Redmond WA 98052 419 USA 421 Email: farooq.bari@att.com 423 Rong Zhang 424 China Telecom 425 No.109 Zhongshandadao avenue 426 Guangzhou 510630 427 China 429 Email: zhangr@gsta.com 431 Satoru Matsushima 432 SoftBank Telecom 433 1-9-1 Higashi-Shinbashi, Munato-ku 434 Tokyo 435 Japan 437 Email: satoru.matsushima@g.softbank.co.jp