idnits 2.17.1 draft-ietf-opsawg-capwap-alt-tunnel-06.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 are 38 instances 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2015) is 3083 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: 'RFC3828' is defined on line 891, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Opsawg Working Group R. Zhang 3 Internet-Draft China Telecom 4 Intended status: Standards Track Z. Cao 5 Expires: April 21, 2016 H. Deng 6 China Mobile 7 R. Pazhyannur 8 S. Gundavelli 9 Cisco 10 L. Xue 11 J. You 12 Huawei 13 October 19, 2015 15 Alternate Tunnel Encapsulation for Data Frames in CAPWAP 16 draft-ietf-opsawg-capwap-alt-tunnel-06 18 Abstract 20 Control And Provisioning of Wireless Access Points (CAPWAP) defines a 21 specification to encapsulate a station's data frames between the 22 Wireless Transmission Point (WTP) and Access Controller (AC). 23 Specifically, the station's IEEE 802.11 data frames can be either 24 locally bridged or tunneled to the AC. When tunneled, a CAPWAP data 25 channel is used for tunneling. In many deployments encapsulating 26 data frames to an entity other than the AC (for example to an Access 27 Router (AR)) is desirable. Further, it may also be desirable to use 28 different tunnel encapsulations to carry the stations' data frames. 29 This document provides a specification for this and refers to it as 30 alternate tunnel encapsulation. The alternate tunnel encapsulation 31 allows 1) the WTP to tunnel non-management data frames to an endpoint 32 different from the AC and 2) the WTP to tunnel using one of many 33 known encapsulation types such as IP-IP, IP-GRE, CAPWAP. The WTP may 34 advertise support for alternate tunnel encapsulation during the 35 discovery or join process and AC may select one of the supported 36 alternate tunnel encapsulation types while configuring the WTP. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 21, 2016. 55 Copyright Notice 57 Copyright (c) 2015 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 1.1. Conventions used in this document . . . . . . . . . . . . 7 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 75 2. Alternate Tunnel Encapsulation . . . . . . . . . . . . . . . 8 76 2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8 77 3. Protocol Considerations . . . . . . . . . . . . . . . . . . . 10 78 3.1. Supported Alternate Tunnel Encapsulations . . . . . . . . 10 79 3.2. Alternate Tunnel Encapsulations Type . . . . . . . . . . 11 80 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication . . . 12 81 3.4. CAPWAP based Alternate Tunnel . . . . . . . . . . . . . . 13 82 3.5. PMIPv6 based Alternate Tunnel . . . . . . . . . . . . . . 13 83 3.6. Alternate Tunnel Information Elements . . . . . . . . . . 14 84 3.6.1. Access Router Information Elements . . . . . . . . . 14 85 3.6.2. IEEE 802.11 WLAN Configuration Response . . . . . . . 16 86 3.6.3. Tunnel DTLS Policy Element . . . . . . . . . . . . . 16 87 3.6.4. IEEE 802.11 Tagging Mode Policy Element . . . . . . . 17 88 3.6.5. CAPWAP Transport Protocol Element . . . . . . . . . . 18 89 3.6.6. GRE Key Element . . . . . . . . . . . . . . . . . . . 18 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 92 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 95 7.2. Informative References . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 99 1. Introduction 101 Service Providers are deploying very large Wi-Fi deployments (ranging 102 from hundreds of thousands of Access Points, APs (referred to as WTPs 103 in CAPWAP terminology) to millions of APs. These networks are 104 designed to carry traffic generated from mobile users. The volume in 105 mobile user traffic is already very large and expected to continue 106 growing rapidly. As a result, operators are looking for scalable 107 solutions that can meet the increasing demand. The scalability 108 requirement can be met by splitting the control/management plane from 109 the data plane. This enables the data plane to scale independent of 110 the control/management plane. This specification provides a way to 111 enable such separation. 113 CAPWAP ([RFC5415], [RFC5416]) defines a tunnel mode that describes 114 how the WTP handles the data plane (user traffic). The following 115 types are defined: 117 o Local Bridging: All data frames are locally bridged. 118 o 802.3 Tunnel: All data frames are tunneled to the AC in 802.3 119 format. 120 o 802.11 Tunnel: All data frames are tunneled to the AC in 802.11 121 format. 123 Figure 1 describes a system with Local Bridging. The AC is in a 124 centralized location. The data plane is locally bridged by the WTPs 125 leading to a system with centralized control plane with distributed 126 data plane. This system has two benefits: 1) reduces the scale 127 requirement on data traffic handling capability of the AC and 2) 128 leads to more efficient/optimal routing of data traffic while 129 maintaining centralized control/management. 131 Locally Bridged 132 +-----+ Data Frames +----------------+ 133 | WTP |===============| Access Router | 134 +-----+ +----------------+ 135 \\ 136 \\ CAPWAP Control Channel +----------+ 137 ++=========================| AC | 138 // CAPWAP Data Channel: | | 139 // IEEE 802.11 Mgmt traffic +----------+ 140 // 141 +-----+ +----------------+ 142 | WTP |============== | Access Router | 143 +=====+ +----------------+ 144 Locally Bridged 145 Data Frames 147 Figure 1: Centralized Control with Distributed Data 149 The AC handles control of WTPs. In addition, the AC also handles the 150 IEEE 802.11 management traffic to/ from the stations. There is 151 CAPWAP Control and Data Channel between the WTP and the AC. Note 152 that even though there is no user traffic transported between the WTP 153 and AC, there is still a CAPWAP Data Channel. The CAPWAP Data 154 channel carries the IEEE 802.11 management traffic (like IEEE 802.11 155 Action Frames). 157 Figure 2 shows a system where the tunnel mode is configured to tunnel 158 data frames between the WTP and the AC either using 802.3 Tunnel or 159 802.11 Tunnel configurations. Operators deploy this configuration 160 when they need to tunnel the user traffic. The tunneling requirement 161 may be driven by the need to apply policy at the Access Router or a 162 legal requirement to support lawful intercept of user traffic. This 163 requirement could be met in the locally bridged system (Figure 1) if 164 the access router implemented the required policy. However, in many 165 deployments the operator managing the WTP is different than the 166 operator managing the Access Router. When the operators are 167 different, the policy has to be enforced in a tunnel termination 168 point in the WTP operator's network. 170 +-----+ 171 | WTP | 172 +-----+ 173 \\ 174 \\ CAPWAP Control Channel +----------+ 175 ++=========================| AC | 176 // CAPWAP Data Channel: | | 177 // IEEE 802.11 Mgmt traffic | | 178 // Data Frames +----------+ 179 // 180 +-----+ 181 | WTP | 182 +=====+ 184 Figure 2: Centralized Control and Centralized Data 186 The key difference with the locally bridged system is that the data 187 frames are tunneled to the AC instead of being locally bridged. 188 There are two shortcomings with system in Figure 2. 1) They do not 189 allow the WTP to tunnel data frames to an endpoint different from the 190 AC and 2) They do not allow the WTP to tunnel data frames using any 191 encapsulation other than CAPWAP (as specified in Section 4.4.2 of 192 [RFC5415]). 194 Figure 3 shows a system where the WTP tunnels data frames to an 195 alternate entity different from the AC. The WTP also uses an 196 alternate tunnel encapsulation such as such as L2TP, L2TPv3, IP-in- 197 IP, IP/GRE, etc. This enables 1) independent scaling of data plane 198 and 2) leveraging of commonly used tunnel encapsulations such as 199 L2TP, GRE, etc 200 Alternate Tunnel to AR (L2TPv3, IP-IP, CAPWAP, etc) 201 _________ 202 +-----+ ( ) +-----------------+ 203 | WTP |======+Internet +==============|Access Router(AR)| 204 +-----+ (_________) +-----------------+ 205 \\ ________ CAPWAP Control 206 \\ ( ) Channel +--------+ 207 ++==Internet+========================| AC | 208 // (________)CAPWAP Data Channel: +--------+ 209 // IEEE 802.11 Mgmt traffic 210 // _________ 211 +-----+ ( ) +----------------+ 212 | WTP |====+Internet +================| Access Router | 213 +=====+ (_________) +----------------+ 214 Alternate Tunnel to AR (L2TPv3, IP-IP, CAPWAP, etc) 216 Figure 3: Centralized Control with Alternate Tunnel for Data 218 The WTP may support widely used encapsulation types such as L2TP, 219 L2TPv3, IP-in-IP, IP/GRE, etc. The WTP advertises the different 220 alternate tunnel encapsulation types it can support. The AC 221 configures one of the advertised types. As shown in the figure there 222 is a CAPWAP control and data channel between the WTP and AC. The 223 CAPWAP data channel carries the stations' management traffic as in 224 the case of the locally bridged system. The main reason to maintain 225 a CAPWAP data channel is to maintain similarity with the locally 226 bridged system. The WTP maintains three tunnels: CAPWAP Control, 227 CAPWAP Data, and another alternate tunnel for the data frame. The 228 data frames are transported by an alternate tunnel between the WTP 229 and a tunnel termination point such as an Access Router. This 230 specification describes how the alternate tunnel can be established. 231 The specification defines message elements for the WTP to advertise 232 support for alternate tunnel encapsulation, the AC to configure 233 alternate tunnel encapsulation, and for the WTP to report failure of 234 the alternate tunnel. 236 The alternate tunnel encapsulation also supports the third-party WLAN 237 service provider scenario (i.e. Virtual Network Operator, VNO). 238 Under this scenario, the WLAN provider owns the WTP and AC resources, 239 while the VNOs can rent the WTP resources from the WLAN provider for 240 network access. The AC belonging to the WLAN service provider 241 manages the WTPs in the centralized mode. 243 As shown in Figure 4, VNO 1&2 don't possess the network access 244 resources, however they provide services by acquiring resources from 245 the WLAN provider. Since a WTP is capable of supporting up to 16 246 Service Set Identifiers (SSIDs), the WLAN provider may provide 247 network access service for different providers with different SSIDs. 249 For example, SSID1 is advertised by the WTP for VNO1; while SSID2 is 250 advertised by the WTP for VNO2. Therefore the data traffic from the 251 user can be directly steered to the corresponding access router of 252 the VNO who owns that user. 254 +----+ 255 | AC | 256 +--+-+ 257 CAPWAP-CTL | 258 +-----------------+ 259 | CAPWAP-DATA: IEEE 802.11 Mgmt traffic 260 | 261 WLAN Provider| VNO 1 262 +-----+ CAPWAP-DATA (SSID1) +---------------+ 263 SSID1 | WTP +--------------------------|Access Router 1| 264 SSID2 +--+-++ +---------------+ 265 | | 266 | | VNO 1 267 | | GRE-IPv4-DATA (SSID1) +---------------+ 268 | +---------------------------|Access Router 2| 269 | +---------------+ 270 | 271 | VNO 2 272 | CAPWAP-DATA (SSID2) +---------------+ 273 +-----------------------------|Access Router 3| 274 +---------------+ 276 Figure 4: Third-party WLAN Service Provider 278 1.1. Conventions used in this document 280 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 281 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 282 document are to be interpreted as described in [RFC2119] 284 1.2. Terminology 286 Station (STA): A device that contains an IEEE 802.11 conformant 287 medium access control (MAC) and physical layer (PHY) interface to the 288 wireless medium (WM). 290 Access Controller (AC): The network entity that provides WTP access 291 to the network infrastructure in the data plane, control plane, 292 management plane, or a combination therein. 294 Access Router (AR): A specialized router usually residing at the edge 295 or boundary of a network. This router ensures the connectivity of 296 its network with external networks, a wide area network or the 297 Internet. 299 Wireless Termination Point (WTP), The physical or network entity that 300 contains an RF antenna and wireless Physical Layer (PHY) to transmit 301 and receive station traffic for wireless access networks. 303 CAPWAP Control Channel: A bi-directional flow defined by the AC IP 304 Address, WTP IP Address, AC control port, WTP control port, and the 305 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Control 306 packets are sent and received. 308 CAPWAP Data Channel: A bi-directional flow defined by the AC IP 309 Address, WTP IP Address, AC data port, WTP data port, and the 310 transport-layer protocol (UDP or UDP-Lite) over which CAPWAP Data 311 packets are sent and received. In certain WTP modes, the CAPWAP Data 312 Channel only transports IEEE 802.11 management frames and not the 313 data plane (user traffic). 315 2. Alternate Tunnel Encapsulation 317 2.1. Description 318 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 319 | WTP | | AC | 320 +-+-+-+-+-+-+ +-+-+-+-+-+-+ 321 |Join Request[Supported Alternate Tunnel | 322 | Encapsulations ] | 323 |---------------------------------------->| 324 | | 325 |Join Response | 326 |<----------------------------------------| 327 | | 328 |IEEE 802.11 WLAN Config. Request [ | 329 | IEEE 802.11 Add WLAN, | 330 | Alternate Tunnel Encapsulation ( | 331 | Tunnel Type, Tunnel Info Element) | 332 | ] | 333 |<----------------------------------------| 334 | | 335 | | 336 +-+-+-+-+-+-+ | 337 | Setup | | 338 | Alternate | | 339 | Tunnel | | 340 +-+-+-+-+-+-+ | 341 | | 342 |IEEE 802.11 WLAN Config. Response | 343 |---------------------------------------->| 344 | | 345 | | 346 +-+-+-+-+-+-+ | 347 | Tunnel | | 348 | Failure | | 349 +-+-+-+-+-+-+ | 350 |WTP Alternate Tunnel Failure Indication | 351 |(report failure (AR address(es))) | 352 |---------------------------------------->| 353 | | 354 +-+-+-+-+-+-+-+ | 355 | Tunnel | | 356 | Established | | 357 +-+-+-+-+-+-+-+ | 358 |WTP Alternate Tunnel Failure Indication | 359 |(report clearing failure) | 360 |---------------------------------------->| 361 | | 363 Figure 5: Setup of Alternate Tunnel 365 The above example describes how the alternate tunnel encapsulation 366 may be established. When the WTP joins the AC, it should indicate 367 its alternate tunnel encapsulation capability. The AC determines 368 whether an alternate tunnel configuration is required. If an 369 appropriate alternate tunnel type is selected, then the AC provides 370 the alternate tunnel encapsulation message element containing the 371 tunnel type and a tunnel-specific information element. (The tunnel- 372 specific information element, for example, may contain information 373 like the IP address of the tunnel termination point.) The WTP sets 374 up the alternate tunnel using the alternate tunnel encapsulation 375 message element. 377 On detecting a tunnel failure, WTP shall forward data frames to the 378 AC and discard the frames. In addition, WTP may dissociate existing 379 clients and refuse association requests from new clients. Depending 380 on the implementation and deployment scenario, the AC may choose to 381 reconfigure the WLAN (on the WTP) to a local bridging mode or to 382 tunnel frames to the AC. When the WTP detects an alternate tunnel 383 failure, the WTP informs the AC using a message element, WTP 384 Alternate Tunnel Fail Indication (defined in this specification). 386 The WTP also needs to notify the AC of which AR(s) are unavailable. 387 Particularly, in the VNO scenario, the AC of the WLAN service 388 provider needs to maintain the association of the AR addresses of the 389 VNOs and SSIDs, and provide this information to the WTP for the 390 purpose of load balancing or master-slave mode. 392 The message element has a status field that indicates whether the 393 message denotes reporting a failure or the clearing of the previously 394 reported failure. 396 For the case where AC is unreachable but the tunnel end point is 397 still reachable, the WTP behavior is up to the implementation. For 398 example, the WTP could either choose to tear down the alternate 399 tunnel or let the existing user's traffic continue to be tunneled. 401 3. Protocol Considerations 403 3.1. Supported Alternate Tunnel Encapsulations 405 This message element is sent by a WTP to communicate its capability 406 to support alternate tunnel encapsulations. The message element 407 contains the following fields: 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Num_Tunnels | Tunnel-Type 1 | Tunnel-Type [2..N] 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 Figure 6: Supported Alternate Tunnel Encapsulations 417 o Type: for Supported Alternate Tunnel Encapsulations 418 o Length: The length in bytes is 1 + Num_Tunnels 419 o Num_Tunnels: This refers to number of tunnel types present in the 420 message element. At least one tunnel type must be present. 421 o Tunnel-Type: This is identified by value defined in Section 3.2 423 3.2. Alternate Tunnel Encapsulations Type 425 This message element is sent by the AC. This message element allows 426 the AC to select the alternate tunnel encapsulation. This message 427 element may be provided along with the IEEE 802.11 Add WLAN message 428 element. When the message element is present the following fields of 429 the IEEE 802.11 Add WLAN element shall be set as follows: MAC mode is 430 set to 0 (Local MAC) and Tunnel Mode is set to 0 (Local Bridging). 431 The message element contains the following fields 433 0 1 2 3 434 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 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Tunnel-Type | Info Element Length | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Info Element 439 +-+-+-+-+-+-+-+-+-+ 441 Figure 7: Alternate Tunnel Encapsulations Type 443 o Type: for Alternate Tunnel Encapsulation Type 444 o Length: > 4 445 o Tunnel-Type: The tunnel type is specified by a 2 byte value. This 446 specification defines the values from zero (0) to five (5) as 447 given below. The remaining values are reserved for future use. 449 * 0: CAPWAP. This refers to a CAPWAP data channel described in 450 [RFC5415][RFC5416]. 451 * 1: L2TP. This refers to tunnel encapsulation described in 452 [RFC2661]. 453 * 2: L2TPv3. This refers to tunnel encapsulation described in 454 [RFC3931]. 456 * 3: IP-in-IP. This refers to tunnel encapsulation described in 457 [RFC2003]. 458 * 4: PMIPv6. This refers to the tunneling encapsulation 459 described in [RFC5213] 460 * 5: GRE-IPv4. This refers to GRE encapsulation with IPv4 as the 461 delivery protocol as described in RFC2874. 462 * 6: GRE-IPv6. This refers to GRE encapsulation with IPv6 as the 463 delivery protocol as described in RFC2874. 464 o Info Element: This field contains tunnel specific configuration 465 parameters to enable the WTP to setup the alternate tunnel. This 466 specification provides details for this elements for CAPWAP and 467 PMIPv6. We anticipate that message elements for the other 468 protocols (like L2TPv3, etc) will be defined in other 469 specifications in the future. 471 3.3. IEEE 802.11 WTP Alternate Tunnel Failure Indication 473 The Alternate Tunnel Failure Indication message element is sent by 474 the WTP to inform the AC about the status of the Alternate Tunnel. 475 For the case where WTP establishes data tunnels with multiple ARs 476 (e.g., under VNO scenario), the WTP needs to notify the AC of which 477 AR(s) are unavailable. The message element contains the following 478 fields: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | WLAN ID | Status | Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 . Access Router Information Element . 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 8: IEEE 802.11 WTP Alternate Tunnel Failure Indication 490 o Type: for IEEE 802.11 WTP Alternate Tunnel Failure 491 Indication 492 o Length: == 4 493 o WLAN ID: An 8-bit value specifying the WLAN Identifier. The value 494 MUST be between one (1) and 16. 495 o Status: An 8-bit boolean indicating whether the radio failure is 496 being reported or cleared. A value of zero is used to clear the 497 event, while a value of one is used to report the event. 498 o Access Router Information Element: IPv4 address or IPv6 address or 499 Fully Qualified Domain Name (FQDN), of the Access Router for the 500 alternate tunnel. The Access Router Information Elements allow 501 the WTP to notify the AC of which AR(s) are unavailable. 503 3.4. CAPWAP based Alternate Tunnel 505 If the CAPWAP encapsulation is selected by the AC and configured by 506 the AC to the WTP, the Info Element field defined in Section 3.2 507 should contain the following information: 509 o Access Router Information: IPv4 address or IPv6 address or Fully 510 Qualified Domain Name (FQDN), of the Access Router for the 511 alternate tunnel. 512 o Tunnel DTLS Policy: The CAPWAP protocol allows optional protection 513 of data packets using DTLS. Use of data packet protection on a 514 WTP is not mandatory but determined by the associated AC policy 515 (This is consistent with the WTP behavior described in [RFC5415]). 516 o IEEE 802.11 Tagging Mode Policy: It is used to specify how the 517 CAPWAP data channel packet are to be tagged for QoS purposes (see 518 [RFC5416] for more details). 519 o CAPWAP Transport Protocol: The CAPWAP protocol supports both UDP 520 and UDP-Lite (see RFC3828). When run over IPv4, UDP is used for 521 the CAPWAP data channels. When run over IPv6, the CAPWAP data 522 channel may use either UDP or UDP-lite. 524 The message element structure for CAPWAP encapsulation is shown in 525 Figure 9: 527 0 1 2 3 528 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 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | Tunnel-Type=0 | Info Element Length | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 . Access Router Information Element . 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 . Tunnel DTLS Policy Element . 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 . IEEE 802.11 Tagging Mode Policy Element . 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 . CAPWAP Transport Protocol Element . 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 9: Alternate Tunnel Encapsulation - CAPWAP 543 3.5. PMIPv6 based Alternate Tunnel 545 Proxy Mobile IPv6 (PMIPv6) (defined in [RFC5213]) can also be used 546 for alternate tunnel encapsulation between the WTP and the AR. In 547 this scenario, a WTP acts as the Mobile Access Gateway (MAG) function 548 that manages the mobility-related signaling for a station that is 549 attached to the WTP IEEE 802.11 radio access. The Local Mobility 550 Anchor (LMA) function is at the AR. If PMIPv6 encapsulation is 551 selected by the AC and configured by the AC to a WTP, the Info 552 Element field defined in Section 3.2 should contain the following 553 information: 555 o Access Router (acts as LMA) Information: IPv6 address or Fully 556 Qualified Domain Name (FQDN) for the alternate tunnel endpoint. 558 The message element structure for PMIPv6 encapsulation is shown in 559 Figure 10: 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Tunnel-Type=4 | Info Element Length | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 . Access Router (LMA) Information Element . 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 10: Alternate Tunnel Encapsulation - PMIPv6 571 3.6. Alternate Tunnel Information Elements 573 This section defines the various elements described in Section 3.4 574 and Section 3.5 576 3.6.1. Access Router Information Elements 578 The Access Router Information Elements allow the AC to notify a WTP 579 of which AR(s) are available for establishing a data tunnel. The AR 580 information may be IPv4 address, IPv6 address, or AR domain name. If 581 a WTP obtains the correct AR FQDN, the Name-to-IP address mapping is 582 handled in the WTP (see RFC2782). 584 The following are the Access Router Information Elements defined in 585 this specification. The AC can use one of them to notify the 586 destination information of the data tunnel to the WTP. The Elements 587 containing the AR IPv4 address MUST NOT be used if an IPv6 data 588 channel such as PMIPv6 or GREv6 is used. 590 3.6.1.1. AR IPv4 List Element 592 This Element (see Figure 11) is used by the AC to configure a WTP 593 with the AR IPv4 address available for the WTP to establish the data 594 tunnel for user traffic. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | AR IPv4 Element Type | Length | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 . AR IPv4 Address-1 . 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 . AR IPv4 Address-2 . 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 . AR IPv4 Address-N . 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Figure 11: AR IPv4 List Element 610 Length: This refers to the total length in octets of the element 611 excluding the Type and Length fields. 613 AR IPv4 Address: IPv4 address of the AR. At least one IPv4 address 614 shall be present. Multiple addresses may be provided for load 615 balancing or redundancy. 617 3.6.1.2. AR IPv6 List Element 619 This Element (see Figure 12) is used by the AC to configure a WTP 620 with the AR IPv6 address available for the WTP to establish the data 621 tunnel for user traffic. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | AR IPv6 Element Type | Length | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 . AR IPv6 Address-1 . 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 . AR IPv6 Address-2 . 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 . AR IPv6 Address-N . 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Figure 12: AR IPv6 List Element 637 Length: This refers to the total length in octets of the element 638 excluding the Type and Length fields. 640 AR IPv6 Address: IPv6 address of the AR. At least one IPv6 address 641 shall be present. Multiple addresses may be provided for load 642 balancing or redundancy. 644 3.6.1.3. AR FQDN List Element 646 This Element (see Figure 13) is used by the AC to configure a WTP 647 with AR FQDN available to establish the data tunnel for user traffic. 648 Based on the FQDN, a WTP can acquire the AR IP address via DNS. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | AR FQDN Element Type | Element Length | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Length | AR FQDN-1 . 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Length | AR FQDN-2 . 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Length | AR FQDN-N . 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Figure 13: AR FQDN List Element 664 Element Length: This refers to the total length in octets of the 665 element excluding the Type and element Length fields. 667 Length: The length of each AR FQDN. 669 AR FQDN: An array of variable-length string containing AR FQDN. This 670 can be used to satisfy load-balance and reliability requirements. 672 3.6.2. IEEE 802.11 WLAN Configuration Response 674 Since AC can configure a WTP with more than one AR available for the 675 WTP to establish the data tunnel(s) for user traffic, it may be 676 useful for the WTP to communicate the selected AR. To enable this, 677 the IEEE 802.11 WLAN Configuration Response may contain the AR list 678 element containing the selected AR. 680 3.6.3. Tunnel DTLS Policy Element 682 The AC distributes its DTLS usage policy for the CAPWAP data tunnel 683 between a WTP and the AR. There are multiple supported options, 684 represented by the bit field below as defined in AC Descriptor 685 message elements. The WTP MUST abide by one of the options for 686 tunneling user traffic with AR. The Tunnel DTLS Policy Element obey 687 the definition in [RFC5415]. If there are more than one ARs 688 information provided by the AC for reliability reasons, the same 689 Tunnel DTLS Policy (see Figure 14) is generally applied for all 690 tunnels associated with the ARs. Otherwise, Tunnel DTLS Policy MUST 691 be bonding together with each of the ARs, then WTP will enforce the 692 independent tunnel DTLS policy for each tunnel with a specific AR. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |Tunnel DTLS Element Type | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Reserved |A|D|C|R| 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 . AR Information (optional) . 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Figure 14: Tunnel DTLS Policy Element 706 Reserved: A set of reserved bits for future use. All implementations 707 complying with this protocol MUST set to zero any bits that are 708 reserved in the version of the protocol supported by that 709 implementation. Receivers MUST ignore all bits not defined for the 710 version of the protocol they support. 712 A: If A bit is set, there is an AR information associated with the 713 DTLS policy. There may be an array of pairs binding DTLS policy 714 information and AR information contained in the Tunnel DTLS Policy 715 Element. Otherwise, the same Tunnel DTLS Policy (see Figure 14) is 716 generally applied for all tunnels associated with the ARs configured 717 by the AC. 719 D: DTLS-Enabled Data Channel Supported (see [RFC5415]). 721 C: Clear Text Data Channel Supported (see [RFC5415]). 723 R: A reserved bit for future use abide (see [RFC5415]). 725 3.6.4. IEEE 802.11 Tagging Mode Policy Element 727 In 802.11 networks, IEEE 802.11 Tagging Mode Policy Element is used 728 to specify how the WTP apply the QoS tagging policy when receiving 729 the packets from stations on a particular radio. When the WTP sends 730 out the packet to data channel to the AR(s), the packets have to be 731 tagged for QoS purposes (see [RFC5416]). 733 The IEEE 802.11 Tagging Mode Policy abides the IEEE 802.11 WTP 734 Quality of Service defined in Section 6.22 of [RFC5416]. 736 3.6.5. CAPWAP Transport Protocol Element 738 The CAPWAP data tunnel supports both UDP and UDP-Lite (see RFC3828). 739 When run over IPv4, UDP is used for the CAPWAP data channels. When 740 run over IPv6, the CAPWAP data channel may use either UDP or UDP- 741 lite. The AC specifies and configure the WTP for which transport 742 protocol is to be used for the CAPWAP data tunnel. 744 The CAPWAP Transport Protocol Element abides the definition in 745 Section 4.6.14 of [RFC5415]. 747 0 1 2 3 748 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 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | Type=51 | Length | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Transport | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 Figure 15: CAPWAP Transport Protocol Element 757 Type: 51 for CAPWAP Transport Protocol [RFC5415]. 759 Length: 1 761 Transport: The transport to use for the CAPWAP Data channel. The 762 following enumerated values are supported: 764 1 - UDP-Lite: The UDP-Lite transport protocol is to be used for the 765 CAPWAP Data channel. Note that this option MUST NOT be used if the 766 CAPWAP Control channel is being used over IPv4 and AR address is IPv4 767 contained in the AR Information Element. 769 2 - UDP: The UDP transport protocol is to be used for the CAPWAP Data 770 channel. 772 3.6.6. GRE Key Element 774 If a WTP receives the GRE Key Element in the Alternate Tunnel 775 Encapsulation message element for GREv4 or GREv6 selection, the WTP 776 must insert the GRE Key to the encapsulation packet (see [RFC2890]). 777 An AR acting as decapsulating tunnel endpoint identifies packets 778 belonging to a traffic flow based on the Key value. 780 The GRE Key Element field contains a four octet number defined in 781 [RFC2890]. 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | GRE Key Element Type | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | GRE Key | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 16: GRE Key Element 793 GRE Key: The Key field contains a four octet number which is inserted 794 by the WTP according to [RFC2890]. 796 4. IANA Considerations 798 This document requires the following IANA considerations. 800 o . This specification defines the Supported Alternate 801 Tunnel Encapsulations Type message element in Section 3.1. This 802 elements needs to be registered in the existing CAPWAP Message 803 Element Type registry, defined in [RFC5415]. The Type value for 804 this element needs to be between 1 and 1023 (see Section 15.7 in 805 [RFC5415]). 806 o . This specification defines the Alternate Tunnel 807 Encapsulations Type message element in Section 3.2. This element 808 needs to be registered in the existing CAPWAP Message Element Type 809 registry, defined in [RFC5415]. The Type value for this element 810 needs to be between 1 and 1023. 811 o . This specification defines the IEEE 802.11 WTP 812 Alternate Tunnel Failure Indication message element in 813 Section 3.3. This element needs to be registered in the existing 814 CAPWAP Message Element Type registry, defined in [RFC5415]. The 815 Type value for this element needs to be between 1024 and 2047. 816 o Tunnel-Type: This specification defines the Alternate Tunnel 817 Encapsulations Type message element. This element contains a 818 field Tunnel-Type. The namespace for the field is 16 bits 819 (0-65535)). This specification defines values, zero (0) through 820 six (6) and can be found in Section 3.2. Future allocations of 821 values in this name space are to be assigned by IANA using the 822 "Specification Required" policy. IANA needs to create a registry 823 called CAPWAP Alternate Tunnel-Types. The registry format is 824 given below. 825 o AR IPv4 Element Type: AR IPv4 List Element (see Figure 11) is used 826 by the AC to configure a WTP with the AR IPv4 address available 827 for the WTP to establish the data tunnel for user traffic. 828 o AR IPv6 Element Type: AR IPv6 List Element (see Figure 12) is used 829 by the AC to configure a WTP with the AR IPv6 address available 830 for the WTP to establish the data tunnel for user traffic. 832 o AR FQDN Element Type: AR FQDN Element (see Figure 13) is used by 833 the AC to configure a WTP with AR FQDN available to establish the 834 data tunnel for user traffic. 835 o Tunnel DTLS Element Type: The Tunnel DTLS Policy Element obey the 836 definition in [RFC5415]. 837 o GRE Key Element Type: If a WTP receives the GRE Key Element in the 838 Alternate Tunnel Encapsulation message element for GREv4 or GREv6 839 selection, the WTP must insert the GRE Key to the encapsulation 840 packet 842 Tunnel-Type Type Value Reference 843 CAPWAP 0 [RFC5415],[RFC5416] 844 L2TP 1 [RFC2661] 845 L2TPv3 2 [RFC3931] 846 IP-IP 3 [RFC2003] 847 PMIPv6 4 [RFC5213] 848 GRE-IPv4 5 [RFC2784] 849 GRE-IPv6 6 [RFC2784] 851 5. Security Considerations 853 This document introduces three new CAPWAP WTP message elements. 854 These elements are transported within CAPWAP Control messages as the 855 existing message elements. Therefore, this document does not 856 introduce any new security risks compared to [RFC5415] and [RFC5416]. 857 In CAPWAP, security for CAPWAP Data Channel is optional and security 858 policy is determined by AC. Similarly, the AC determines the 859 security for the Alternate Tunnel between WTP and Alternate Tunnel 860 Encapsulation Gateway. The security considerations described in 861 [RFC5415] and [RFC5416] apply here as well. 863 6. Contributors 865 This document stems from the joint work of Hong Liu, Yifan Chen, 866 Chunju Shao from China Mobile Research. The authors would like to 867 thank Zongpeng Du and Jin Li for their valuable comments. 869 7. References 871 7.1. Normative References 873 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, DOI 874 10.17487/RFC2003, October 1996, 875 . 877 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 878 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 879 RFC 2661, DOI 10.17487/RFC2661, August 1999, 880 . 882 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 883 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 884 DOI 10.17487/RFC2784, March 2000, 885 . 887 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 888 RFC 2890, DOI 10.17487/RFC2890, September 2000, 889 . 891 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., 892 and G. Fairhurst, Ed., "The Lightweight User Datagram 893 Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 894 2004, . 896 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 897 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 898 3931, DOI 10.17487/RFC3931, March 2005, 899 . 901 [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., 902 Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 903 5213, DOI 10.17487/RFC5213, August 2008, 904 . 906 [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 907 Ed., "Control And Provisioning of Wireless Access Points 908 (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/ 909 RFC5415, March 2009, 910 . 912 [RFC5416] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, 913 Ed., "Control and Provisioning of Wireless Access Points 914 (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, DOI 915 10.17487/RFC5416, March 2009, 916 . 918 7.2. Informative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 922 RFC2119, March 1997, 923 . 925 Authors' Addresses 927 Rong Zhang 928 China Telecom 929 No.109 Zhongshandadao avenue 930 Guangzhou 510630 931 China 933 Email: zhangr@gsta.com 935 Zhen Cao 936 China Mobile 937 Xuanwumenxi Ave. No. 32 938 Beijing 100871 939 China 941 Phone: +86-10-52686688 942 Email: zhen.cao@gmail.com, caozhen@chinamobile.com 944 Hui Deng 945 China Mobile 946 No.32 Xuanwumen West Street 947 Beijing 100053 948 China 950 Email: denghui@chinamobile.com 952 Rajesh S. Pazhyannur 953 Cisco 954 170 West Tasman Drive 955 San Jose, CA 95134 956 USA 958 Email: rpazhyan@cisco.com 960 Sri Gundavelli 961 Cisco 962 170 West Tasman Drive 963 San Jose, CA 95134 964 USA 966 Email: sgundave@cisco.com 967 Li Xue 968 Huawei 969 No.156 Beiqing Rd. Z-park, HaiDian District 970 Beijing 971 China 973 Email: xueli@huawei.com 975 Jianjie You 976 Huawei 977 101 Software Avenue, Yuhuatai District 978 Nanjing, 210012 979 China 981 Email: youjianjie@huawei.com