idnits 2.17.1 draft-ietf-opsawg-capwap-hybridmac-02.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 (February 14, 2014) is 3724 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) == Unused Reference: 'RFC4564' is defined on line 368, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4564 Summary: 1 error (**), 0 flaws (~~), 3 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: August 18, 2014 R. Pazhyannur 6 Cisco 7 F. Bari 8 AT&T 9 R. Zhang 10 China Telecom 11 S. Matsushima 12 SoftBank Telecom 13 February 14, 2014 15 IEEE 802.11 MAC Profile for CAPWAP 16 draft-ietf-opsawg-capwap-hybridmac-02 18 Abstract 20 CAPWAP defines two entities Wireless Transmission Point (WTP) and 21 Access Controller (AC). CAPWAP also defines two MAC (Medium Access 22 Control) modes for IEEE 802.11 WTPs: Split and Local MAC . For each 23 MAC mode, CAPWAP describes how the MAC functionality is split between 24 the WTP and AC. However, certain functions have not been clearly 25 defined. For example for the Split MAC mode, the IEEE 802.11 26 encryption is specified as located in either the AC or the WTP with 27 no clear way for the AC to inform the WTP where it should be. This 28 lack of specification leads to interoperability especially when AC 29 and WTP come from different vendors. To solve the problem, this 30 specification defines a IEEE 802.11 MAC profile where each profile 31 specifies an unambigous division of functionality between the WTP and 32 AC. The IEEE 802.11 MAC profile is used as follows: The WTP informs 33 the AC of the supported profiles during the discovery or join process 34 and the AC configures the WTP with one of the supported profiles 35 while configuring a WLAN. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on August 18, 2014. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Conventions used in this document . . . . . . . . . . . . . . 4 73 3. IEEE MAC Profile Descriptions . . . . . . . . . . . . . . . . 4 74 3.1. Split MAC with WTP encryption . . . . . . . . . . . . . . 4 75 3.2. Split MAC with AC encryption . . . . . . . . . . . . . . 5 76 3.3. IEEE 802.11 MAC Profile Frame Exchange . . . . . . . . . 6 77 4. MAC Profile Message Element Definitions . . . . . . . . . . . 7 78 4.1. IEEE 802.11 Supported MAC Profiles . . . . . . . . . . . 7 79 4.2. IEEE 802.11 MAC Profile . . . . . . . . . . . . . . . . . 8 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 84 9. Normative References . . . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 The CAPWAP protocol supports two MAC modes of operation: Split and 90 Local MAC, as described in [RFC5415], [RFC5416]. However, there are 91 MAC functions that have not been clearly defined. For example IEEE 92 802.11 encryption is specified as located in either in the AC or the 93 WTP with no clear way to negotiate where it should be located. 94 Because different vendors have their own definition of the MAC mode, 95 many MAC layer functions are mapped differently to either the WTP or 96 the AC by different vendors. Therefore, depending upon the vendor, 97 the operators in their deployments have to perform different 98 configurations based on implementation of the two modes by their 99 vendor. If there is no clear specification then operators will 100 experience difficulty in interoperating WTPs and ACs from different 101 vendors. 103 Figure 1 quoted from [RFC5416], illustrates how the functions are 104 processed in different places in the Local MAC and Split MAC mode. 105 Specifically, note that in the Split MAC mode the IEEE 802.11 106 encryption/decryption is specified as WTP/AC implying that it could 107 be at either location. 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Functions | Local MAC | Split MAC | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 | |Distribution Service | WTP/AC | AC | 113 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 | |Integration Service | WTP | AC | 115 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | |Beacon Generation | WTP | WTP | 117 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | |Probe Response Generation| WTP | WTP | 119 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Function |Power Mgmt | WTP | WTP | 121 + |/Packet Buffering | | | 122 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | |Fragmentation | WTP | WTP/AC | 124 + |/Defragmentation | | | 125 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | |Assoc/Disassoc/Reassoc | WTP/AC | AC | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | |Classifying | WTP | AC | 129 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | 802.11 QoS |Scheduling | WTP | WTP/AC | 131 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | |Queuing | WTP | WTP | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 | |IEEE 802.1X/EWTP | AC | AC | 135 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 | 802.11 RSN |RSNA Key Management | WTP | AC | 137 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | |IEEE 802.11 | WTP | WTP/AC | 139 + |Encryption/Decryption | | | 140 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: Functions in Local MAC and Split MAC 144 To solve this problem, this specification introduces IEEE 802.11 MAC 145 profle. The MAC profile unamabigously specifies where the various 146 MAC fucntionality should be located. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 3. IEEE MAC Profile Descriptions 156 A IEEE MAC Profile refers to a description of how the MAC 157 functionality is split between the WTP and AC shown in Figure 1 159 3.1. Split MAC with WTP encryption 161 The functional split for the Split MAC with WTP encryption is 162 provided in Figure 2. This profile is similar to the Split MAC 163 except that IEEE 802.11 encryption/decryption is at the WTP. Note 164 that fragmentation is always done at the same entity as the 165 encryption. Consequently, in this profile fragmentation/ 166 defragmentation is also done only at the WTP Note that scheduling 167 functionality is denoted as WTP/AC. As explained in [RFC5416], this 168 means that the admission control component of IEEE 802.11 resides on 169 the AC, the real-time scheduling and queuing functions are on the 170 WTP. 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Functions | Profile | 174 | | 0 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | |Distribution Service | AC | 177 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | |Integration Service | AC | 179 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | |Beacon Generation | WTP | 181 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | |Probe Response Generation| WTP | 183 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Function |Power Mgmt | WTP | 185 + |/Packet Buffering | | 186 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | |Fragmentation | WTP | 188 + |/Defragmentation | | 189 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | |Assoc/Disassoc/Reassoc | AC | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | |Classifying | AC | 193 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | 802.11 QoS |Scheduling | WTP/AC | 195 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | |Queuing | WTP | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | |IEEE 802.1X/EWTP | AC | 199 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | 802.11 RSN |RSNA Key Management | AC | 201 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | |IEEE 802.11 | WTP | 203 + |Encryption/Decryption | | 204 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2: Functions in Split MAC with WTP Encryption 208 3.2. Split MAC with AC encryption 210 The functional split for the Split MAC with AC encryption is provided 211 in Figure 3. This profile is similar to the Split MAC except that 212 IEEE 802.11 encryption/decryption is done only at the AC. Since 213 fragmentation is always done at the same entity as the encryption, in 214 this rofile, AC does fragmentation/defragmentation. 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Functions | Profile | 218 | | 1 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | |Distribution Service | AC | 221 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | |Integration Service | AC | 223 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | |Beacon Generation | WTP | 225 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | |Probe Response Generation| WTP | 227 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Function |Power Mgmt | WTP | 229 + |/Packet Buffering | | 230 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | |Fragmentation | AC | 232 + |/Defragmentation | | 233 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | |Assoc/Disassoc/Reassoc | AC | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | |Classifying | AC | 237 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | 802.11 QoS |Scheduling | WTP | 239 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | |Queuing | WTP | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | |IEEE 802.1X/EWTP | AC | 243 + IEEE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | 802.11 RSN |RSNA Key Management | AC | 245 + (WPA2) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | |IEEE 802.11 | AC | 247 + |Encryption/Decryption | | 248 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 3: Functions in Split MAC with AC encryption 252 3.3. IEEE 802.11 MAC Profile Frame Exchange 254 An example of message exchange using the the IEEE 802.11 MAC Profile 255 message element is shown in Figure 4. The WTP informs the AC of the 256 various MAC profiles it supports. This happens either in a Discovery 257 Request message or the Join Request message. The AC determines the 258 appropriate profile and the configures the WTP with the profile while 259 configuring the WLAN. 261 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 262 | WTP | | AC | 263 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 264 |Join Request[Supported IEEE 802.11 | 265 | MAC Profiles ] | 266 |---------------------------------------->| 267 | | 268 |Join Response | 269 |<----------------------------------------| 270 | | 271 |IEEE 802.11 WLAN Config. Request [ | 272 | IEEE 802.11 Add WLAN, | 273 | IEEE 802.11 MAC Profile | 274 | ] | 275 |<----------------------------------------| 276 | | 277 |IEEE 802.11 WLAN Config. Response | 278 |---------------------------------------->| 280 Figure 4: Message Exchange For Negotiating MAC Profile 282 4. MAC Profile Message Element Definitions 284 4.1. IEEE 802.11 Supported MAC Profiles 286 The IEEE 802.11 Supported MAC Profile message element allows the WTP 287 to communicate the profiles it supports. The Discovery Request 288 message, Primary Discovery Request message, and Join Request message 289 may include one such message element. 291 0 1 2 3 292 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 293 +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 294 | Num_Profiles | Profile_1 | Profile_[2..N].. 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 297 Figure 5: IEEE 802.11 Supported MAC Profiles 299 o Type: TBD for IEEE 802.11 Supported MAC Profiles 300 o Num_Profiles >=1: This refers to number of profiles present in 301 this messaage element. There must be at least one profile. 302 o Profile: Each profile is idnentified by a value specified in 303 Section 4.2. 305 4.2. IEEE 802.11 MAC Profile 307 The IEEE 802.11 MAC Profile message element allows the AC to select a 308 profile. This messsage element may be provided along with the IEEE 309 802.11 ADD WLAN message element while configuring a WLAN on the WTP. 311 0 1 2 3 4 5 6 7 312 +=+-+-+-+-+-+-+-+ 313 | Profile | 314 +-+-+-+-+-+-+-+-+ 316 Figure 6: IEEE 802.11 MAC Profile 318 o Type: TBD for IEEE 802.11 MAC Profile 319 o Profile: The profile is identified by a value as given below 321 * 0: This refers to the Split MAC Profile with WTP encryption 322 * 1: This refers to the Split MAC Profile with AC encryption 324 5. Security Considerations 326 This document doesn't specify security risk difference from 327 [RFC5416]. Please refer to the Security section of [RFC5416] 329 6. IANA Considerations 331 This document requires the following IANA actions. 333 o This specification defines a new message element, IEEE 802.11 334 Supported MAC Profiles. The format of this option is described in 335 Section 4.1. This value needs to be regsitered in the existing 336 CAPWAP Message Element Type registry, defined in [RFC5415]. 337 o This specification defines a new message element, IEEE 802.11 MAC 338 Profile. The format of this option is described in Section 4.2. 339 This value needs to be regsitered in the existing CAPWAP Message 340 Element Type registry, defined in [RFC5415]. 341 o The Profile field in the IEEE 802.11 Supported MAC Profiles 342 message element and IEEE 802.11 MAC Profile message element (see 343 Section 4.2) is used to denote the MAC profile. This document 344 defines two values, zero (0) and one (1), and the remaining values 345 (2-255) are controlled and maintained by IANA and require an 346 Expert Review. 348 7. Contributors 350 Yifan Chen chenyifan@chinamobile.com 352 Naibao Zhou zhounaibao@chinamobile.com 354 8. Acknowledgments 356 The authors are grateful for extremely valuable suggestions from 357 Dorothy Stanley in developing this specification. 359 Guidance from management team: Melinda Shore, Scott Bradner, Chris 360 Liljenstolpe, Benoit Claise, Joel Jaeggli, Dan Romascanu are highly 361 appreciated. 363 9. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, March 1997. 368 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang, 369 "Objectives for Control and Provisioning of Wireless 370 Access Points (CAPWAP)", RFC 4564, July 2006. 372 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 373 Provisioning of Wireless Access Points (CAPWAP) Protocol 374 Specification", RFC 5415, March 2009. 376 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 377 Provisioning of Wireless Access Points (CAPWAP) Protocol 378 Binding for IEEE 802.11", RFC 5416, March 2009. 380 Authors' Addresses 382 Chunju Shao 383 China Mobile 384 No.32 Xuanwumen West Street 385 Beijing 100053 386 China 388 Email: shaochunju@chinamobile.com 389 Hui Deng 390 China Mobile 391 No.32 Xuanwumen West Street 392 Beijing 100053 393 China 395 Email: denghui@chinamobile.com 397 Rajesh S. Pazhyannur 398 Cisco 399 170 West Tasman Drive 400 San Jose, CA 95134 401 USA 403 Email: rpazhyan@cisco.com 405 Farooq Bari 406 AT&T 407 7277 164th Ave NE 408 Redmond WA 98052 409 USA 411 Email: farooq.bari@att.com 413 Rong Zhang 414 China Telecom 415 No.109 Zhongshandadao avenue 416 Guangzhou 510630 417 China 419 Email: zhangr@gsta.com 421 Satoru Matsushima 422 SoftBank Telecom 423 1-9-1 Higashi-Shinbashi, Munato-ku 424 Tokyo 425 Japan 427 Email: satoru.matsushima@g.softbank.co.jp