Network Working Group D. Liu Internet-Draft China Mobile Intended status: Standards Track R. Zhang Expires: January 4, 2015 China Telecom L. Xue J. Kaippallimalil Huawei R. Pazhyannur S. Gundavelli Cisco July 3, 2014 Specification Alternate Tunnel Information for Data Frames in WLAN draft-xue-opsawg-capwap-alt-tunnel-information-00 Abstract In IEEE 802.11 Wireless Local Area Network (WLAN) architecture, in order to meet the scalability requirement, customer data frames are desired to be distributed to an endpoint (e.g. Access Router AR) different from the Access Controller (AC). For tunneling the data frames, there are many known alternate tunnel technologies can be used, such as IP-GRE, IP-IP, CAPWAP, L2TP/L2TPv3 etc. To assist a WTP to set up the alternate tunnels, this document extends the message elements to report WTP the specific alternate tunnel information. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." Liu, et al. Expires January 4, 2015 [Page 1] Internet-Draft Information for alternate tunnel in WLAN July 2014 This Internet-Draft will expire on January 4, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Data Frame Alternate Tunnel in WLAN . . . . . . . . . . . . . 3 2.1. CAPWAP . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4. IP-GRE . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Alternate Tunnel Information TLV . . . . . . . . . . . . . . 5 3.1. CAPWAP Information TLV . . . . . . . . . . . . . . . . . 5 3.2. L2TP Information TLV . . . . . . . . . . . . . . . . . . 8 3.3. L2TPv3 Information TLV . . . . . . . . . . . . . . . . . 9 3.4. IP-GRE Tunnel Information TLV . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction Control and Provisioning of Wireless Access Points (CAPWAP) ( [RFC5415][RFC5416] )defines CAPWAP tunnel mode which can be used to encapsulate a station's data frames and control/management frames between the Wireless Transmission Point (WTP) and Access Controller (AC). The customer data traffic on WTP can be either locally bridged or tunnelled to the AC. Practically, some operators who have deployed large numbers of WTPs desire to distribute the data traffic to an different entity rather than AC for scalability reasons. An Liu, et al. Expires January 4, 2015 [Page 2] Internet-Draft Information for alternate tunnel in WLAN July 2014 split architecture tunnelling data frames to ARs rather than ACs is defined in [I-D.ietf-opsawg-capwap-alt-tunnel], Figure 1. Tunnel to AR _________ +-----+ ( ) +-----------------+ | WTP |======+Internet +==============|Access Router(AR)| +-----+ (_________} +-----------------+ \\ ________ \\ ( ) CAPWAP +--------+ ++==Internet+===============| AC | // ( ) +--------+ // ________ +-----+// ( ) +----------------+ | WTP |====+Internet +================| Access Router | +=====+ (_________} +----------------+ Tunnel to AR Figure 1: Figure 1: Centralized Control with Distributed Data A generic container for the extension message elements for this architecture have been already defined in [I-D.ietf-opsawg-capwap-alt-tunnel]. The IEEE 802.11 Alternate Tunnel Encapsulation message element Figure 2defined in [I-D.ietf-opsawg-capwap-alt-tunnel],allows the AC to select the alternate tunnel encapsulation and reports some tunnel specific information to WTP. Indeed, there are many protocols may be used for this data frames alternate tunnel, such as IP-IP, IP-GRE, L2TP/ L2TPv3, CAPWAP, etc. The specific tunnel information for each of these potential tunnel protocols are defined in this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Tunnel Type | Tunnel Specific Information +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 2: Figure 2: Alternate Tunnel Encapsulations Type 2. Data Frame Alternate Tunnel in WLAN 2.1. CAPWAP CAPWAP protocol ( [RFC5415][RFC5416]) may be used for data tunnel between WTP and AR asFigure 1. According to CAPWAP with IEEE 802.11 WLAN networks [RFC5416], WTP needs CAPWAP data tunnel information so as to distribute data frames to CAPWAP data tunnel to AR. The following specific CAPWAP data tunnel information (not-exhaustive) should be configured on WTP,more details are described in Section 3.1. Liu, et al. Expires January 4, 2015 [Page 3] Internet-Draft Information for alternate tunnel in WLAN July 2014 o Access Router Information: IPv4 address, IPv6 address, Fully Qualified Domain Name (FQDN) o Tunnel DTLS Policy o IEEE 802.11 Tagging Mode Policy 2.2. L2TP Layer Two Tunneling Protocol (L2TP) can pass PPP frames over an L2TP tunnel within a UDP datagram. When AC selects the L2TP as the alternate tunnel encapsulation and reports the selection to WTP, WTP instates the L2TP data tunnel establishment with a specific AR. This AR address should be configured to WTP during the calling request from hosts attaching to the WTP. Additionally, there are some more tunnel information which need to configure according to [RFC2661], such as Maximum Transmission Unit (MTU) information and IPSec policy for L2TP. The following specific tunnel information (not-exhaustive) are listed,more details are described in Section 3.2. o Access Router Information: IPv4 address, IPv6 address, Fully Qualified Domain Name (FQDN) o MTU o IPSec Policy 2.3. L2TPv3 L2TPv3 borrows largely from L2TPv2. L2TPv3 tunnel can be used over multiple Packet-Switched Network (PSN) such as IP, UDP, Frame Relay, ATM, MPLS, etc. L2TPv3 tunnels the data packets may be utilized with or without the L2TP control channel, either via manual configuration or via other signaling methods to per-configure or distribute L2TP session information. In this document, L2TPv3 control channel is assumed to establish, manage and tear down the L2TPv3 data tunnel. Similar tunnel information as L2TP(not-exhaustive) in Section 2.2 should be configured on WTP,such as AR information, MTU, IPSec Policy. More details are described in Section 3.3. 2.4. IP-GRE In order to encapsulated data traffic using GRE ([RFC1701][RFC2784] ), WTP needs at least to obtain the destination node IP address of a GRE tunnel (e.g.,AR address) to encapsulate the GRE packets. Optionally, GRE Key Suboption ( [RFC2784] [RFC2890] ) is needed for WTP so as to configure the complementary tunnel information. If WTP obtains the GRE Key suboption, the key MUST be inserted into the GRE Liu, et al. Expires January 4, 2015 [Page 4] Internet-Draft Information for alternate tunnel in WLAN July 2014 encapsulation header. The Key is used for identifying extra context information about the received payload on AR. The payload packets without the correspondent GRE Key or with an unmatched GRE Key will be silently dropped. The following specific GRE data tunnel information (not-exhaustive) should be configured on WTP, more details are described in Section 3.4. o Access Router Information: IPv4 address, IPv6 address, Fully Qualified Domain Name (FQDN) o GRE Key 3. Alternate Tunnel Information TLV 3.1. CAPWAP Information TLV New tunnel information TLVs are defined when CAPWAP alternate tunnel (Tunnel Type =0) is used : The AR IPv4 Address TLV: This TLV is used by AC to configure AR IPv4 address to WTP. WTP establishes CAPWAP data tunnel with the specific AR. The format is shown as follows. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ . AR IPv4 Address . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: AR IPv4 Address TLV AR IPv4 Address: The AR IPv4 address serving WTP in the network. Due to load-sharing and reliability requirement, there may be more than one AR IPv4 address provided. The AR IPv4 address can be formatted via TLV for sub-TLVFigure 4: Liu, et al. Expires January 4, 2015 [Page 5] Internet-Draft Information for alternate tunnel in WLAN July 2014 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Prefer| AR IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . +-+-+-+-+ Figure 4: Load-sharing AR IPv4 Sub-TLV Type: 1 Prefer: The priority/cost of the following AR IPv4 address AR IPv4 Address: the IPv4 address of ARs which can serve the WTP in the network. AR IPv6 Address TLV: This TLV is used by AC to configure AR IPv6 address to WTP. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=2 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ . AR IPv6 Address . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: AR IPv6 Address TLV AR IPv6 Address: The AR IPv6 prefix serving WTP in the network.Due to load-sharing and reliability requirement, there may be more than one AR IPv6 address provided. The AR IPv6 address can be formatted via TLV for sub-TLVFigure 6: Liu, et al. Expires January 4, 2015 [Page 6] Internet-Draft Information for alternate tunnel in WLAN July 2014 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Prefer| AR IPv6 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . +-+-+-+-+ Figure 6: Load-sharing AR IPv6 sub-TLV Type: 1 Prefer: The priority/cost of the following AR IPv6 address AR FQDN TLV: This TLV is used by AC to configure FQDN to WTP. Based on the FQDN, WTP can acquire AR IP address via DNS. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=3 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ . AR FQDN . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: AR FQDN TLV AR FQDN: The AR FQDN serving WTP in the network.Due to reliability reasons, more than one AR FQDN can be provided via sub-TLV: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Prefer| FQDN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . +-+-+-+-+ Load-sharing AR FQDN sub-TLV Type: 1 Prefer: The priority/cost of the following AR FQDN. Liu, et al. Expires January 4, 2015 [Page 7] Internet-Draft Information for alternate tunnel in WLAN July 2014 Tunnel DTLS Policy TLV: This TLV reports WTP the tunnel Datagram Transport Layer Security (DTLS) policy of CAPWAP data tunnel with AR. If the policy value is set to 1, WTP establishes a secure DTLS session with the selected AR. Otherwise, the CAPWAP data frames are not secured using DTLS. Especially, if there are multiple ARs used due to load balance or reliability reasons, the tunnel DTLS policy TLV Figure 8must be carried together with each of the AR sub-TLV. WTP must clear the tunnel DTLS policy for each tunnel to a AR. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Tunnel DTLS Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Tunnel DTLS Policy TLV Tunnel DTLS Policy: If value is 1, the CAPWAP date frames to AR will be secured using DTLS. Otherwise, DTLS is not used. IEEE 802.11 Tagging Mode Policy TLV: This TLVFigure 9 reports WTP the way to tag IEEE 802.11 packet. CAPWAP ([RFC5415][RFC5416]) defines a tunnel mode that specifies the frame tunneling type to be used for 802.11 data frames from stations. The WTP may tunnel client data frames to the AR, using 802.3 frame tunnel mode or 802.11 frame tunnel mode. If value is 1, the WTP will use 802.3 frame tunnel mode, if value is 0, the WTP will forward 802.11 frame directly to the AR. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | Tunnel DTLS Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: IEEE 802.11 Tagging Mode Policy TLV 3.2. L2TP Information TLV The following new TLVs are needed when the alternate tunnel is L2TP (Tunnel Type =1) : Liu, et al. Expires January 4, 2015 [Page 8] Internet-Draft Information for alternate tunnel in WLAN July 2014 The TLVs mentioned Figure 3Figure 5Figure 7should be used for WTP to identify ARs. WTP initiates L2TP tunnel establishment procedure with the specific ARs. MTU TLVFigure 10: L2TP protocol makes no special efforts to optimize packet fragmentation. AC reports the MTU which can be provided on WTP. Generally, the MTU on WTP should be no more than the MTU on the path minus the encapsulation headers, such as IP header, L2TP header, PPP header, etc. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | MTU TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: MTU TLV IPSec Policy TLV: IPSec may be used for end to end L2TP security. If the value is set to 1, the L2TP packet encryption is provided by IPsec mode. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | IPSec Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: IPSec Policy TLV 3.3. L2TPv3 Information TLV The following new TLVs are used when the alternate tunnel is L2TPv3 (Tunnel Type =2) : The TLVs mentioned Figure 3Figure 5Figure 7should be used for WTP to identify ARs. WTP initiates L2TPv3 tunnel establishment procedure with the specific ARs. MTU TLVFigure 10: AC reports the MTU can be provided on WTP. Generally, the MTU on WTP should be no more than the MTU on the path minus the encapsulation headers, such as IP header, L2TP header etc. Liu, et al. Expires January 4, 2015 [Page 9] Internet-Draft Information for alternate tunnel in WLAN July 2014 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | MTU TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: MTU TLV IPSec Policy TLV: IPSec may be used for end to end L2TPv3 security issue. If the value is set to 1, the L2TPv3 packet encryption is provided by IPsec mode. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | IPSec Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: IPSec Policy TLV L2TPv3 Encapsulation TLV: L2TPv3 can be used over IP or UDP as defined in [RFC3931]. While L2TPv3 over IP is not as NAT-friendly as L2TP over UDP, so AC need to configure the proper L2TPv3 encapsulation to WTP in NAT scenario. If the value is 1, L2TPv3 will be send over IP, otherwise, L2TPv3 over UDP will be applied. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=5 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | L2TPv3 Encapsulation | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: L2TPv3 Encapsulation TLV 3.4. IP-GRE Tunnel Information TLV The following new IP-GRE tunnel information TLVs are used, when tunnel is IP-GRE (Tunnel Type =4) : The TLVs mentioned Figure 3Figure 5Figure 7should be used for WTP to identify ARs. WTP encapsulates the customer upstream packet via AR address as destination address in GRE header. Liu, et al. Expires January 4, 2015 [Page 10] Internet-Draft Information for alternate tunnel in WLAN July 2014 GRE Key TLV: If WTP receives the GRE Key TLV, WTP must insert the GRE Key to the encapsulation packet. And AR as decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key value. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=4 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ | GRE Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP-GRE Tunnel GRE Key TLV 4. IANA Considerations To be specified in later versions. 5. Security Considerations To be specified in later versions. 6. References 6.1. Normative References [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. Liu, et al. Expires January 4, 2015 [Page 11] Internet-Draft Information for alternate tunnel in WLAN July 2014 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006. [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, March 2009. [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11", RFC 5416, March 2009. 6.2. Informative References [I-D.ietf-opsawg-capwap-alt-tunnel] Zhang, R., Cao, Z., Deng, H., Pazhyannur, R., Gundavelli, S., and L. Xue, "Alternate Tunnel Encapsulation for Data Frames in CAPWAP", draft-ietf-opsawg-capwap-alt-tunnel-00 (work in progress), May 2014. Authors' Addresses Dapeng Liu China Mobile Unit 2, 28 Xuanwumenxi Ave, Xuanwu District Beijing 100053 China Email: liudapeng@chinamobile.com Rong Zhang China Telecom No. 109 Zhongshandadao avenue Guangzhou 510630 China Email: zhangr@gsta.com Liu, et al. Expires January 4, 2015 [Page 12] Internet-Draft Information for alternate tunnel in WLAN July 2014 Li Xue Huawei No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, HaiDian District Beijing 100095 China Email: xueli@huawei.com John Kaippallimalil Huawei 5430 Legacy Drive, Suite 175 Plano, TX 75024 Email: john.kaippallimalil@huawei.com Rajesh S. Pazhyannur Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: rpazhyan@cisco.com Sri Gundavelli Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Liu, et al. Expires January 4, 2015 [Page 13]