[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-opsawg-capwap-alt-tunnel

Network Working Group                                           R. Zhang
Internet-Draft                                             China Telecom
Intended status: Standards Track                                  Z. Cao
Expires: April 25, 2014                                          H. Deng
                                                            China Mobile
                                                           R. Pazhyannur
                                                           S. Gundavelli
                                                                   Cisco
                                                        October 22, 2013


        Alternate Tunnel Encapsulation for Data Frames in CAPWAP
                    draft-zhang-opsawg-capwap-cds-01

Abstract

   CAPWAP ([RFC5416]) defines two tunneling modes for encapsulating data
   frames from stations associated with WLAN: 802.3 Tunnel and 802.11
   Tunnel modes.  This document provides for an alternate tunnel
   encapsulation.  The alternate tunnel encapsulation allows 1) the WTP
   to tunnel non-management data frames to an endpoint different from
   the AC and 2) allows the WTP to tunnel using one of many known
   encapsulation types such as IP-IP, IP-GRE, CAPWAP.  The WTP may
   advertise support for Alternate Tunnel encapsulation during the
   discovery process and AC may select one of the supported Alternate
   Tunnel encapsulate types during the WTP configuration.  Further, the
   AC may configure WTP to enable the alternate tunnel encapsulation.

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."

   This Internet-Draft will expire on April 25, 2014.

Copyright Notice





Zhang, et al.            Expires April 25, 2014                 [Page 1]


Internet-Draft              Alternate Tunnel                October 2013


   Copyright (c) 2013 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
     1.1.  Conventions used in this document . . . . . . . . . . . .   4
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Alternate Tunnel Encapsulation  . . . . . . . . . . . . . . .   5
     2.1.  Supported Alternate Tunnel Encpsulation . . . . . . . . .   5
     2.2.   Alternate Tunnel Encapsulation . . . . . . . . . . . . .   5
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   CAPWAP ([RFC5415], [RFC5416]) defines a tunnel mode that specifies
   the frame tunneling type to be used for 802.11 data frames from all
   stations associated with the WLAN.  The following types are
   supported:

   o  Local Bridging: All user traffic is to be locally bridged.
   o  802.3 Tunnel: All user traffic is to be tunneled to the AC in
      802.3 format.
   o  802.11 Tunnel: All user traffic is to be tunneled to the AC in
      802.11 format.

   There are two shortcomings with currently specified tunneled modes:
   1) it does not allow the WTP to tunnel data frames to an endpoint
   different from the AC and 2) it does not allow the WTP to tunnel data
   frames using any encapsulation other than CAPWAP (as specified in
   Section 4.4.2 of [RFC5415]).  Next, we describe what is driving the
   above mentioned two requirements.



Zhang, et al.            Expires April 25, 2014                 [Page 2]


Internet-Draft              Alternate Tunnel                October 2013


   Some operators deploying large number of Access Points prefer to
   centralize the management and control of Access Points (AP) while
   distributing the handling of data traffic to increase scaling.  This
   motivates an architecture as shown in Figure 1 that has the Access
   Controller in a centralized location and one or more tunnel gateways
   (or Access Routers) that terminate the data tunnels from the various
   WTPs. central data center.  This split architecture has two benefits
   over an architecture where data traffic is aggregated at the AC: 1)
   reduces the scale requriement on data traffic handling capability of
   the AR and 2) leads to more efficient/optimal routing of data
   traffic.


   +-----+   DATA   +----------------+
   | WTP |==========|  Access Router |
   +-----+          +----------------+
         \\
          \\   CTL(CAPWAP)           +--------+
             ++======================+   AC   |
            //                       +--------+
           //
   +-----+//  DATA   +----------------+
   | WTP |===========|  Access Router |
   +=====+           +----------------+


            Figure 1: Centralized Control with Distributed Data

   The above system (shown in Figure 1) could be achieved by setting the
   tunnel mode to Local bridging.  In such a case the AC would handle
   control of WTPs as well as handle the management traffic to/from the
   stations.  The data frames (non-management) from the stations would
   be handled by the local Access Router.  However, in many deployments
   the operator managing the WTPs/AC may be different from the operator
   providing the internet connectivity to the WTPs.  Further, the WTP
   operator may want (or be required by legal/regulatory requirements)
   to tunnel the traffic back to an Access Router in its network as
   shown in Figure 2.  The tunneling requirement may be driven by the
   need to apply policy at the Access Router or a legal requirement to
   support lawful intercept of user traffic.  This motivates the need
   for the WTP to support an alternate Tunnel encapsulation support
   where the data tunnels from the WTP are terminated at an AR (and more
   specifically at an end point different from the AC).

                 _________
   +-----+      (         )              +----------------+
   | WTP |======+Internet +==============|  Access Router |
   +-----+      (_________}              +----------------+



Zhang, et al.            Expires April 25, 2014                 [Page 3]


Internet-Draft              Alternate Tunnel                October 2013


         \\      ________
          \\    (        ) CAPWAP(CNTL)  +--------+
             ++==Internet+===============|   AC   |
            //  (        )               +--------+
           //  ________
   +-----+//  (         )                +----------------+
   | WTP |====+Internet +================|  Access Router |
   +=====+    (_________}                +----------------+


            Figure 2: Centralized Control with Distributed Data

   In the case where the WTP is tunneling data frames to an AR (and not
   the AC), the choice of tunnel encapsulation need not be restricted
   only to CAPWAP (as described in Section 4.4.2 of [RFC5415]).  In
   fact, the WTP may additionally support other widely used
   encapsulation types such as L2TP, L2TPv3, IP-in-IP, IP/GRE, etc.  The
   WTP may advertise the different alterante tunnel encapsulation types
   supported and the AC can select one of the supported encapsulation
   types.

1.1.  Conventions used in this document

   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]

1.2.  Terminology

   Access Controller (AC): The network entity that provides WTP access
   to the network infrastructure in the data plane, control plane,
   management plane, or a combination therein.

   Access Point (AP): the same with Wireless Termination Point (WTP),
   The physical or network entity that contains an RF antenna and
   wireless Physical Layer (PHY) to transmit and receive station traffic
   for wireless access networks.

   CAPWAP Control Plane: A bi-directional flow over which CAPWAP Control
   packets are sent and received.

   CAPWAP Data Plane: A bi-directional flow over which CAPWAP Data
   frames are sent and received.

   EAP: Extensible Authentication Protocol, the EAP framework is
   specified in [RFC3748].





Zhang, et al.            Expires April 25, 2014                 [Page 4]


Internet-Draft              Alternate Tunnel                October 2013


2.  Alternate Tunnel Encapsulation

2.1.  Supported Alternate Tunnel Encpsulation

   The IEEE 802.11 Supported Alternate Tunnel Encapsulations message
   element allow the WTP to communicate the supported tunnels.  The
   Discovery Request message, Primary Discovery Request message, and
   Join Request message may include one such message element

        0               1               2               3
        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
       +=+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
       | Num_Tunnels   |  Tunnel_1     |  Tunnel_[2..N]..
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

          Figure 3: IEEE 802.11 Supported Tunnels Encapsulations

   o  Type: TBD for IEEE 802.11 Supported MAC Profiles
   o  Num_Tunnels >=1: This refers to number of profiles presnt in this
      messaage element.  There must be at least one profile.
   o  Tunnel: Each Tunnel is idnentified by a value given in Section 2.2

2.2.  Alternate Tunnel Encapsulation

   The IEEE 802.11 Alternate Tunnel Encapsulation message element allows
   the AC to select the profile.  This messsage element may be provided
   along with the IEEE 802.11 ADD WLAN message element while configuring
   a WLAN on the WTP.


           0 1 2 3 4 5 6 7
          +=+-+-+-+-+-+-+-+
          |  Tunnel Encap |
          |   Type        |
          +-+-+-+-+-+-+-+-+

                     Figure 4: IEEE 802.11 MAC Profile

   o  Type: TBD for IEEE 802.11 MAC Profile
   o  Tunnel Encap Type: The profile is idnentified by a value as given
      below

      *  0: CAPWAP data channel as described in [RFC5415][RFC5416]
      *  1: L2TP
      *  2: L2TPv3
      *  3: IP-in-IP
      *  4: IP/GRE




Zhang, et al.            Expires April 25, 2014                 [Page 5]


Internet-Draft              Alternate Tunnel                October 2013


3.  IANA Considerations

   To be specified.

4.  Security Considerations

   Security considerations for the CAPWAP protocol has been analyzed in
   Section 12 of [RFC5415].  This document does not introduce other
   security issues besides what has been analyzed in RFC5415.

5.  Contributors

   This document stems from the joint work of Hong Liu, Yifan Chen,
   Chunju Shao from China Mobile Research.  Thank all the contributors
   of this document.

6.  References

6.1.  Normative References

   [RFC5415]  Calhoun, P., Montemurro, M., and D. Stanley, "Control And
              Provisioning of Wireless Access Points (CAPWAP) Protocol
              Specification", RFC 5415, March 2009.

6.2.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [RFC4564]  Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. Yang,
              "Objectives for Control and Provisioning of Wireless
              Access Points (CAPWAP)", RFC 4564, July 2006.

   [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.

   [RFC5417]  Calhoun, P., "Control And Provisioning of Wireless Access
              Points (CAPWAP) Access Controller DHCP Option", RFC 5417,
              March 2009.




Zhang, et al.            Expires April 25, 2014                 [Page 6]


Internet-Draft              Alternate Tunnel                October 2013


Authors' Addresses

   Rong Zhang
   China Telecom
   No.109 Zhongshandadao avenue
   Guangzhou  510630
   China

   Email: zhangr@gsta.com


   Zhen Cao
   China Mobile
   Xuanwumenxi Ave. No. 32
   Beijing  100871
   China

   Phone: +86-10-52686688
   Email: zehn.cao@gmail.com, caozhen@chinamobile.com


   Hui Deng
   China Mobile
   No.32 Xuanwumen West Street
   Beijing  100053
   China

   Email: denghui@chinamobile.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





Zhang, et al.            Expires April 25, 2014                 [Page 7]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/