idnits 2.17.1 draft-ietf-opsawg-capwap-alt-tunnel-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (May 5, 2014) is 3641 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Zhang 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Cao 5 Expires: November 6, 2014 H. Deng 6 China Mobile 7 R. Pazhyannur 8 S. Gundavelli 9 Cisco 10 L. Xue 11 Huawei 12 May 5, 2014 14 Alternate Tunnel Encapsulation for Data Frames in CAPWAP 15 draft-ietf-opsawg-capwap-alt-tunnel-00 17 Abstract 19 CAPWAP defines a specification to encapsulate a station's data frames 20 between the Wireless Transmission Point (WTP) and Access Controller 21 (AC) using CAPWAP. Specifically, the station's IEEE 802.11 data 22 frames can be either locally bridged or tunneled to the AC. When 23 tunneled, a CAPWAP data channel is used for tunneling. In many 24 deployments it is desirable to encapsulate date frames to an entity 25 different from the AC for example to an Access Router (AR). Further, 26 it may also be desirable to use different tunnel encapsulations to 27 carry the stations' data frames. This document provides a 28 specification for this and refers to it as Alternate tunnel 29 encapsulation. The Alternate tunnel encapsulation allows 1) the WTP 30 to tunnel non-management data frames to an endpoint different from 31 the AC and 2) the WTP to tunnel using one of many known encapsulation 32 types such as IP-IP, IP-GRE, CAPWAP. The WTP may advertise support 33 for Alternate tunnel encapsulation during the discovery or join 34 process and AC may select one of the supported Alternate Tunnel 35 encapsulation types while configuring the WTP. 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 November 6, 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 1.1. Conventions used in this document . . . . . . . . . . . . 5 73 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Alternate Tunnel Encapsulation . . . . . . . . . . . . . . . 6 75 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2. Supported Alternate Tunnel Encapsulations . . . . . . . . 8 77 2.3. Alternate Tunnel Encapsulations Type . . . . . . . . . . 8 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6.1. Normative References . . . . . . . . . . . . . . . . . . 10 83 6.2. Informative References . . . . . . . . . . . . . . . . . 10 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 Service Providers are deploying very large Wi-Fi deployments (ranging 89 from hundreds of thousands of APs to millions of APs). These 90 networks are designed to carry traffic generated from mobile users. 91 The volume in mobile user traffic is already very large (in the order 92 of petabytes per day) and expected to continue growing rapidly. As a 93 result, operators are looking for solutions that can scale to meet 94 the increasing demand. One way to meet the scalability requirement 95 is to split the control/management plane from the data plane. This 96 separation enables the data plane be scaled independently of the 97 control/management plane. This document provides a description of a 98 CAPWAP specification change that enables the separation of data plane 99 from control plane. 101 CAPWAP ([RFC5415], [RFC5416]) defines a tunnel mode that specifies 102 the frame tunneling type to be used for 802.11 data frames from 103 stations associated with the WLAN. The following types are 104 supported: 106 o Local Bridging: All user traffic is to be locally bridged. 107 o 802.3 Tunnel: All user traffic is to be tunneled to the AC in 108 802.3 format. 109 o 802.11 Tunnel: All user traffic is to be tunneled to the AC in 110 802.11 format. 112 There are two shortcomings with currently specified tunneled modes: 113 1) it does not allow the WTP to tunnel data frames to an endpoint 114 different from the AC and 2) it does not allow the WTP to tunnel data 115 frames using any encapsulation other than CAPWAP (as specified in 116 Section 4.4.2 of [RFC5415]). Next, we describe what is driving the 117 above mentioned two requirements. 119 Some operators deploying large number of Access Points prefer to 120 centralize the management and control of Access Points while 121 distributing the handling of data traffic to increase scaling. This 122 motivates an architecture as shown in Figure 1 that has the AC in a 123 centralized location and one or more tunnel gateways (or Access 124 Routers) that terminate the data tunnels from the various WTPs. This 125 split architecture has two benefits over an architecture where data 126 traffic is aggregated at the AC: 1) reduces the scale requirement on 127 data traffic handling capability of the AC and 2) leads to more 128 efficient/optimal routing of data traffic. 130 Locally Bridged 131 +-----+ DATA +----------------+ 132 | WTP |==========| Access Router | 133 +-----+ +----------------+ 134 \\ 135 \\ CAPWAP +--------+ 136 ++======================+ AC | 137 // +--------+ 138 // 139 +-----+// DATA +----------------+ 140 | WTP |===========| Access Router | 141 +=====+ +----------------+ 142 Locally Bridged 144 Figure 1: Centralized Control with Distributed Data 146 The above system (shown in Figure 1) could be achieved by setting the 147 tunnel mode to Local bridging. In such a case the AC would handle 148 control of WTPs as well as handle the management traffic to/from the 149 stations. There is CAPWAP Control and Data Channel between the WTP 150 and the AC. The CAPWAP Data channel carries the IEEE 802.11 151 management traffic (like IEEE 802.11 Action Frames). The station's 152 data frames are locally bridged, i.e., not carried over the CAPWAP 153 data channel. The station's data frames are handled by the Access 154 Router. However, in many deployments the operator managing the WTPs/ 155 AC may be different from the operator providing the internet 156 connectivity to the WTPs. Further, the WTP operator may want (or be 157 required by legal/regulatory requirements) to tunnel the traffic back 158 to an Access Router in its network as shown in Figure 2. The 159 tunneling requirement may be driven by the need to apply policy at 160 the Access Router or a legal requirement to support lawful intercept 161 of user traffic. What this means is that local bridging does not 162 meet their requirements. Their requriements are met either by having 163 the WTP tunnel the station's traffic to the AC or the WTP support an 164 alternate tunnel, i.e., a tunnel to an alternate entity different 165 from the AC. This is the motivation for Alternate Tunnel 166 encapsulation support where the data tunnels from the WTP are 167 terminated at an AR (and more specifically at an end point different 168 from the AC). 170 Tunnel to AR _________ 171 +-----+ ( ) +-----------------+ 172 | WTP |======+Internet +==============|Access Router(AR)| 173 +-----+ (_________} +-----------------+ 174 \\ ________ 175 \\ ( ) CAPWAP +--------+ 176 ++==Internet+===============| AC | 177 // ( ) +--------+ 178 // ________ 179 +-----+// ( ) +----------------+ 180 | WTP |====+Internet +================| Access Router | 181 +=====+ (_________} +----------------+ 182 Tunnel to AR 184 Figure 2: Centralized Control with Distributed Data 186 In the case where the WTP is tunneling data frames to an AR (and not 187 the AC), the choice of tunnel encapsulation need not be restricted 188 only to CAPWAP (as described in Section 4.4.2 of [RFC5415]). In 189 fact, the WTP may additionally support other widely used 190 encapsulation types such as L2TP, L2TPv3, IP-in-IP, IP/GRE, etc. The 191 WTP may advertise the different alternate tunnel encapsulation types 192 supported and the AC can select one of the supported encapsulation 193 types. As shown in the figure there is still a CAPWAP control and 194 data channel between the WTP and AC wherein the CAPWAP data channel 195 carries the stations' management traffic. Thus the WTP will maintain 196 three tunnels: CAPWAP Control, CAPWAP Data, and another (alternate) 197 tunnel to the AR. The main reason to maintain a CAPWAP data channel 198 is to minimize the changes on the WTP and AC required to transport 199 stations' management frames (like EAP, IEEE 802.11 Action Frames). 200 These management frames are transported over the CAPWAP data channel 201 as they are done for case when the WTP's tunnel mode is configured as 202 the local bridging. In this specification we describe how the WTP 203 can be configured with this alternate tunnel. 205 1.1. Conventions used in this document 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in [RFC2119] 211 1.2. Terminology 213 Station (STA): A device that contains an IEEE 802.11 conformant 214 medium access control (MAC) and physical layer (PHY) interface to the 215 wireless medium (WM). 217 Access Controller (AC): The network entity that provides WTP access 218 to the network infrastructure in the data plane, control plane, 219 management plane, or a combination therein. 221 Wireless Termination Point (WTP), The physical or network entity that 222 contains an RF antenna and wireless Physical Layer (PHY) to transmit 223 and receive station traffic for wireless access networks. 225 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 226 Address, WTP IP Address, AC control port, WTP control port, and the 227 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Control 228 packets are sent and received. 230 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 231 Address, WTP IP Address, AC data port, WTP data port, and the 232 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data 233 packets are sent and received. 235 2. Alternate Tunnel Encapsulation 237 2.1. Description 238 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 239 | WTP | | AC | 240 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 241 |Join Request[Supported Alternate Tunnel | 242 | Encapsulations ] | 243 |---------------------------------------->| 244 | | 245 |Join Response | 246 |<----------------------------------------| 247 | | 248 |IEEE 802.11 WLAN Config. Request [ | 249 | IEEE 802.11 Add WLAN, | 250 | Alternate Tunnel Encapsulation ( | 251 | Tunnel Type, Tunnel Specific Info) | 252 | ] | 253 |<----------------------------------------| 254 | | 255 |IEEE 802.11 WLAN Config. Response | 256 |---------------------------------------->| 257 | | 258 | | 259 +-+-+-+-+-+-+ | 260 | Setup | | 261 | Alternate | | 262 | Tunnel | | 263 +-+-+-+-+-+-+ | 264 | | 265 |WTP Event Request[Alt Tunnel Established]| 266 |---------------------------------------->| 267 | | 268 | | 269 +-+-+-+-+-+-+ | 270 | Tunnel | | 271 | Failure | | 272 | | | 273 +-+-+-+-+-+-+ | 274 | | 275 |Change State Event[Tunnel Failure] | 276 |---------------------------------------->| 278 Figure 3: Setup of Alternate Tunnel 280 The above example describes how the alternate tunnel encapsulation 281 may be established. When the WTP joins the AC, it should indicate 282 its alternate tunnel encapsulation capability. The AC would 283 determine whether an alternate tunnel configuration is required. If 284 required, it would select an appropriate alternate tunnel 285 encapsulation. The AC provides the alternate tunnel encapsulation 286 message element that provides both the tunnel-type and tunnel 287 specific information. The tunnel specific information may contain 288 configuration information to help the WTP setup the tunnel. For 289 example, the IP address of the access router that will terminate the 290 WTP tunnel. Once the WTP sets up the tunnel, the WTP may inform the 291 AC about the tunnel setup. Correspondingly, if the WTP discovers 292 that the tunneled link to the AR has failed, then it may inform the 293 AC. 295 2.2. Supported Alternate Tunnel Encapsulations 297 This message element enables a WTP to communicate its capability to 298 support alternate tunnel encapsulations to the AC. The WTP may 299 commmunicate its capability during the discovery or join process. 301 0 1 2 3 302 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 303 +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 304 | Num_Tunnels | Tunnel_1 | Tunnel_[2..N].. 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 307 Figure 4: Supported Alternate Tunnel Encapsulations 309 o Type: TBD for Supported Tunnel Encapsulations 310 o Num_Tunnels >=1: This refers to number of profiles presnt in this 311 messaage element. There must be at least one profile. 312 o Tunnel: Each Tunnel is identified by value defined in the Tunnel 313 Type field in Section 2.3 315 2.3. Alternate Tunnel Encapsulations Type 317 The IEEE 802.11 Alternate Tunnel Encapsulation message element allows 318 the AC to select the alternate tunnel encapsulation. This messsage 319 element may be provided along with the IEEE 802.11 Add WLAN message 320 element. When the message element is present the following fields of 321 the IEEE 802.11 Add WLAN element shall be set as follows: MAC mode is 322 set to 0 (Local MAC) and Tunnel Mode is set to 0 (Local Bridging). 324 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 1 2 3 4 5 6 7 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 326 | Tunnel Type | Tunnel Specific 327 | | Information 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 330 Figure 5: Alternate Tunnel Encapsulations Type 332 o Type: TBD for Alternate Tunnel Encapsulation Type 333 o Tunnel Type: The profile is identified by a value given below 335 * 0: CAPWAP data channel as described in [RFC5415][RFC5416] 336 * 1: L2TP 337 * 2: L2TPv3 338 * 3: IP-in-IP 339 * 4: IP/GRE 340 o Tunnel Specific Information: This field contains tunnel specific 341 information that is used to configure the WTP with parameters 342 needed for alternate tunnel setup. 344 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 1 2 3 4 5 6 7 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 346 | Length | Data 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 349 Figure 6: Tunnel Specific Information 351 * Length: 352 * Data: The data field would contain tunnel specific information 353 to assist the WTP in setting up the alternate tunnel. For 354 example if the tunnel type is CAPWAP then the data field would 355 contain the following (non-exhaustive) list of parameters 357 + Access Router IPv4 address 358 + Access Router IPv6 address 359 + Tunnel DTLS Policy 360 + IEEE 802.11 Tagging Policy 362 This specification only defines a generic container for such 363 message elements. We anticipate that these message elements 364 (for the different protocols) will be defined in separate 365 documents, potentially one for each tunneling protocols. See 366 [I-D.xue-opsawg-capwap-separation-capability] for example of 367 such a specification. 369 3. IANA Considerations 371 To be specified in later versions 373 4. Security Considerations 375 To be specified in later versions. 377 5. Contributors 379 This document stems from the joint work of Hong Liu, Yifan Chen, 380 Chunju Shao from China Mobile Research. 382 6. References 384 6.1. Normative References 386 [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And 387 Provisioning of Wireless Access Points (CAPWAP) Protocol 388 Specification", RFC 5415, March 2009. 390 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and 391 Provisioning of Wireless Access Points (CAPWAP) Protocol 392 Binding for IEEE 802.11", RFC 5416, March 2009. 394 6.2. Informative References 396 [I-D.xue-opsawg-capwap-separation-capability] 397 Xue, L., Du, Z., Liu, D., Zhang, R., and J. 398 Kaippallimalil, "Capability Announcement and AR Discovery 399 in CAPWAP Control and Data Channel Separation", draft-xue- 400 opsawg-capwap-separation-capability-01 (work in progress), 401 October 2013. 403 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 404 Requirement Levels", BCP 14, RFC 2119, March 1997. 406 Authors' Addresses 408 Rong Zhang 409 China Telecom 410 No.109 Zhongshandadao avenue 411 Guangzhou 510630 412 China 414 Email: zhangr@gsta.com 416 Zhen Cao 417 China Mobile 418 Xuanwumenxi Ave. No. 32 419 Beijing 100871 420 China 422 Phone: +86-10-52686688 423 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 424 Hui Deng 425 China Mobile 426 No.32 Xuanwumen West Street 427 Beijing 100053 428 China 430 Email: denghui@chinamobile.com 432 Rajesh S. Pazhyannur 433 Cisco 434 170 West Tasman Drive 435 San Jose, CA 95134 436 USA 438 Email: rpazhyan@cisco.com 440 Sri Gundavelli 441 Cisco 442 170 West Tasman Drive 443 San Jose, CA 95134 444 USA 446 Email: sgundave@cisco.com 448 Li Xue 449 Huawei 450 No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, HaiDian District 451 Beijing 452 China 454 Email: xueli@huawei.com