Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5416

Control and Provisioning of Wireless Access Points (CAPWAP) Protocol Binding for IEEE 802.11

Pages: 76
Proposed Standard
Errata
Part 1 of 3 – Pages 1 to 21
None   None   Next

Top   ToC   RFC5416 - Page 1
Network Working Group                                    P. Calhoun, Ed.
Request for Comments: 5416                           Cisco Systems, Inc.
Category: Standards Track                             M. Montemurro, Ed.
                                                      Research In Motion
                                                         D. Stanley, Ed.
                                                          Aruba Networks
                                                              March 2009


  Control and Provisioning of Wireless Access Points (CAPWAP) Protocol
                        Binding for IEEE 802.11

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
Top   ToC   RFC5416 - Page 2

Abstract

Wireless LAN product architectures have evolved from single autonomous access points to systems consisting of a centralized Access Controller (AC) and Wireless Termination Points (WTPs). The general goal of centralized control architectures is to move access control, including user authentication and authorization, mobility management, and radio management from the single access point to a centralized controller. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol.

Table of Contents

1. Introduction ....................................................4 1.1. Goals ......................................................5 1.2. Conventions Used in This Document ..........................5 1.3. Terminology ................................................5 2. IEEE 802.11 Binding .............................................7 2.1. CAPWAP Wireless Binding Identifier .........................7 2.2. Split MAC and Local MAC Functionality ......................7 2.2.1. Split MAC ...........................................7 2.2.2. Local MAC ..........................................12 2.3. Roaming Behavior ..........................................15 2.4. Group Key Refresh .........................................16 2.5. BSSID to WLAN ID Mapping ..................................17 2.6. CAPWAP Data Channel QoS Behavior ..........................18 2.6.1. IEEE 802.11 Data Frames ............................18 2.6.1.1. 802.1p Support ............................19 2.6.1.2. DSCP Support ..............................19 2.6.2. IEEE 802.11 MAC Management Messages ................21 2.7. Run State Operation .......................................21 3. IEEE 802.11 Specific CAPWAP Control Messages ...................21 3.1. IEEE 802.11 WLAN Configuration Request ....................22 3.2. IEEE 802.11 WLAN Configuration Response ...................23 4. CAPWAP Data Message Bindings ...................................23 5. CAPWAP Control Message Bindings ................................25 5.1. Discovery Request Message .................................25 5.2. Discovery Response Message ................................25 5.3. Primary Discovery Request Message .........................25 5.4. Primary Discovery Response Message ........................26 5.5. Join Request Message ......................................26 5.6. Join Response Message .....................................26 5.7. Configuration Status Request Message ......................26 5.8. Configuration Status Response Message .....................27 5.9. Configuration Update Request Message ......................27
Top   ToC   RFC5416 - Page 3
      5.10. Station Configuration Request ............................28
      5.11. Change State Event Request ...............................28
      5.12. WTP Event Request ........................................28
   6. IEEE 802.11 Message Element Definitions ........................29
      6.1. IEEE 802.11 Add WLAN ......................................29
      6.2. IEEE 802.11 Antenna .......................................35
      6.3. IEEE 802.11 Assigned WTP BSSID ............................36
      6.4. IEEE 802.11 Delete WLAN ...................................37
      6.5. IEEE 802.11 Direct Sequence Control .......................37
      6.6. IEEE 802.11 Information Element ...........................38
      6.7. IEEE 802.11 MAC Operation .................................39
      6.8. IEEE 802.11 MIC Countermeasures ...........................41
      6.9. IEEE 802.11 Multi-Domain Capability .......................42
      6.10. IEEE 802.11 OFDM Control .................................43
      6.11. IEEE 802.11 Rate Set .....................................44
      6.12. IEEE 802.11 RSNA Error Report From Station ...............44
      6.13. IEEE 802.11 Station ......................................46
      6.14. IEEE 802.11 Station QoS Profile ..........................47
      6.15. IEEE 802.11 Station Session Key ..........................48
      6.16. IEEE 802.11 Statistics ...................................50
      6.17. IEEE 802.11 Supported Rates ..............................54
      6.18. IEEE 802.11 Tx Power .....................................54
      6.19. IEEE 802.11 Tx Power Level ...............................55
      6.20. IEEE 802.11 Update Station QoS ...........................56
      6.21. IEEE 802.11 Update WLAN ..................................57
      6.22. IEEE 802.11 WTP Quality of Service .......................61
      6.23. IEEE 802.11 WTP Radio Configuration ......................63
      6.24. IEEE 802.11 WTP Radio Fail Alarm Indication ..............65
      6.25. IEEE 802.11 WTP Radio Information ........................66
   7. IEEE 802.11 Binding WTP Saved Variables ........................67
      7.1. IEEE80211AntennaInfo ......................................67
      7.2. IEEE80211DSControl ........................................67
      7.3. IEEE80211MACOperation .....................................67
      7.4. IEEE80211OFDMControl ......................................67
      7.5. IEEE80211Rateset ..........................................67
      7.6. IEEE80211TxPower ..........................................67
      7.7. IEEE80211QoS ..............................................68
      7.8. IEEE80211RadioConfig ......................................68
   8. Technology Specific Message Element Values .....................68
      8.1. WTP Descriptor Message Element, Encryption
           Capabilities Field ........................................68
   9. Security Considerations ........................................68
      9.1. IEEE 802.11 Security ......................................68
   10. IANA Considerations ...........................................70
      10.1. CAPWAP Wireless Binding Identifier .......................70
      10.2. CAPWAP IEEE 802.11 Message Types .........................70
      10.3. CAPWAP Message Element Type ..............................70
      10.4. IEEE 802.11 Key Status ...................................71
Top   ToC   RFC5416 - Page 4
      10.5. IEEE 802.11 QoS ..........................................71
      10.6. IEEE 802.11 Auth Type ....................................71
      10.7. IEEE 802.11 Antenna Combiner .............................71
      10.8. IEEE 802.11 Antenna Selection ............................72
      10.9. IEEE 802.11 Session Key Flags ............................72
      10.10. IEEE 802.11 Tagging Policy ..............................72
      10.11. IEEE 802.11 WTP Radio Fail ..............................72
      10.12. IEEE 802.11 WTP Radio Type ..............................73
      10.13. WTP Encryption Capabilities .............................73
   11. Acknowledgments ...............................................73
   12. References ....................................................73
      12.1. Normative References .....................................73
      12.2. Informative References ...................................75

1. Introduction

The CAPWAP protocol [RFC5415] defines an extensible protocol to allow an Access Controller to manage wireless agnostic Wireless Termination Points. The CAPWAP protocol itself does not include any specific wireless technologies; instead, it relies on a binding specification to extend the technology to a particular wireless technology. This specification defines the Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Binding Specification for use with the IEEE 802.11 Wireless Local Area Network protocol. Use of CAPWAP control message fields, new control messages, and message elements are defined. The minimum required definitions for a binding-specific Statistics message element, Station message element, and WTP Radio Information message element are included. Note that this binding only supports the IEEE 802.11-2007 specification. Of note, this binding does not support the ad hoc network mode defined in the IEEE 802.11-2007 standard. This specification also does not cover the use of data frames with the four-address format, commonly referred to as Wireless Bridges, whose use is not specified in the IEEE 802.11-2007 standard. This protocol specification does not currently officially support IEEE 802.11n. That said, the protocol does allow a WTP to advertise support for an IEEE 802.11n radio; however, the protocol does not allow for any of the protocol's additional features to be configured and/or used. New IEEE protocol specifications published outside of this document (e.g., IEEE 802.11v, IEEE 802.11r) are also not supported through this binding, and in addition to IEEE 802.11n, must be addressed either through a separate CAPWAP binding, or an update to this binding.
Top   ToC   RFC5416 - Page 5
   In order to address immediate market needs for standards still being
   developed by the IEEE 802.11 standards body, the WiFi Alliance
   created interim pseudo-standards specifications.  Two such
   specifications are widely used in the industry, namely the WiFi
   Protect Access [WPA] and the WiFi MultiMedia [WMM] specifications.
   Given their widespread adoption, this CAPWAP binding requires the use
   of these two specifications.

1.1. Goals

The goals of this CAPWAP protocol binding are to make the capabilities of the CAPWAP protocol available for use in conjunction with IEEE 802.11 wireless networks. The capabilities to be made available can be summarized as: 1. To centralize the authentication and policy enforcement functions for an IEEE 802.11 wireless network. The AC may also provide centralized bridging, forwarding, and encryption of user traffic. Centralization of these functions will enable reduced cost and higher efficiency by applying the capabilities of network processing silicon to the wireless network, as in wired LANs. 2. To enable shifting of the higher-level protocol processing from the WTP. This leaves the time-critical applications of wireless control and access in the WTP, making efficient use of the computing power available in WTPs that are subject to severe cost pressure. The CAPWAP protocol binding extensions defined herein apply solely to the interface between the WTP and the AC. Inter-AC and station-to-AC communication are strictly outside the scope of this document.

1.2. 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 RFC 2119 [RFC2119].

1.3. Terminology

This section contains definitions for terms used frequently throughout this document. However, many additional definitions can be found in [IEEE.802-11.2007]. 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.
Top   ToC   RFC5416 - Page 6
   Basic Service Set (BSS): A set of stations controlled by a single
   coordination function.

   Distribution: The service that, by using association information,
   delivers medium access control (MAC) service data units (MSDUs)
   within the distribution system (DS).

   Distribution System Service (DSS): The set of services provided by
   the distribution system (DS) that enable the medium access control
   (MAC) layer to transport MAC service data units (MSDUs) between
   stations that are not in direct communication with each other over a
   single instance of the wireless medium (WM).  These services include
   the transport of MSDUs between the access points (APs) of basic
   service sets (BSSs) within an extended service set (ESS), transport
   of MSDUs between portals and BSSs within an ESS, and transport of
   MSDUs between stations in the same BSS in cases where the MSDU has a
   multicast or broadcast destination address, or where the destination
   is an individual address but the station sending the MSDU chooses to
   involve the DSS.  DSSs are provided between pairs of IEEE 802.11
   MACs.

   Integration: The service that enables delivery of medium access
   control (MAC) service data units (MSDUs) between the distribution
   system (DS) and an existing, non-IEEE 802.11 local area network (via
   a portal).

   Station (STA): A device that contains an IEEE 802.11 conformant
   medium access control (MAC) and physical layer (PHY) interface to the
   wireless medium (WM).

   Portal: The logical point at which medium access control (MAC)
   service data units (MSDUs) from a non-IEEE 802.11 local area network
   (LAN) enter the distribution system (DS) of an extended service set
   (ESS).

   WLAN: In this document, WLAN refers to a logical component
   instantiated on a WTP device.  A single physical WTP may operate a
   number of WLANs.  Each Basic Service Set Identifier (BSSID) and its
   constituent wireless terminal radios is denoted as a distinct WLAN on
   a physical WTP.

   Wireless Termination Point (WTP): The physical or network entity that
   contains an IEEE 802.11 RF antenna and wireless PHY to transmit and
   receive station traffic for wireless access networks.
Top   ToC   RFC5416 - Page 7

2. IEEE 802.11 Binding

This section describes use of the CAPWAP protocol with the IEEE 802.11 Wireless Local Area Network protocol, including Local and Split MAC operation, Group Key Refresh, Basic Service Set Identification (BSSID) to WLAN Mapping, IEEE 802.11 MAC management frame Quality of Service (Qos) tagging and Run State operation.

2.1. CAPWAP Wireless Binding Identifier

The CAPWAP Header, defined in Section 4.3 of [RFC5415] requires that all CAPWAP binding specifications have a Wireless Binding Identifier (WBID) assigned. This document, which defines the IEEE 802.11 binding, uses the value one (1).

2.2. Split MAC and Local MAC Functionality

The CAPWAP protocol, when used with IEEE 802.11 devices, requires specific behavior from the WTP and the AC to support the required IEEE 802.11 protocol functions. For both the Split and Local MAC approaches, the CAPWAP functions, as defined in the taxonomy specification [RFC4118], reside in the AC. To provide system component interoperability, the WTP and AC MUST support 802.11 encryption/decryption at the WTP. The WTP and AC MAY support 802.11 encryption/decryption at the AC.

2.2.1. Split MAC

This section shows the division of labor between the WTP and the AC in a Split MAC architecture. Figure 1 shows the separation of functionality between CAPWAP components.
Top   ToC   RFC5416 - Page 8
        Function                               Location
            Distribution Service                      AC
            Integration Service                       AC
            Beacon Generation                         WTP
            Probe Response Generation                 WTP
            Power Mgmt/Packet Buffering               WTP
            Fragmentation/Defragmentation             WTP/AC
            Assoc/Disassoc/Reassoc                    AC

       IEEE 802.11 QoS
            Classifying                               AC
            Scheduling                                WTP/AC
            Queuing                                   WTP

       IEEE 802.11 RSN
            IEEE 802.1X/EAP                           AC
            RSNA Key Management                       AC
            IEEE 802.11 Encryption/Decryption         WTP/AC

     Figure 1: Mapping of 802.11 Functions for Split MAC Architecture

   In a Split MAC Architecture, the Distribution and Integration
   services reside on the AC, and therefore all user data is tunneled
   between the WTP and the AC.  As noted above, all real-time IEEE
   802.11 services, including the Beacon and Probe Response frames, are
   handled on the WTP.

   All remaining IEEE 802.11 MAC management frames are supported on the
   AC, including the Association Request frame that allows the AC to be
   involved in the access policy enforcement portion of the IEEE 802.11
   protocol.  The IEEE 802.1X [IEEE.802-1X.2004], Extensible
   Authentication Protocol (EAP) [RFC3748] and IEEE Robust Security
   Network Association (RSNA) Key Management [IEEE.802-11.2007]
   functions are also located on the AC.  This implies that the
   Authentication, Authorization, and Accounting (AAA) client also
   resides on the AC.

   While the admission control component of IEEE 802.11 resides on the
   AC, the real-time scheduling and queuing functions are on the WTP.
   Note that this does not prevent the AC from providing additional
   policy and scheduling functionality.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.  This figure represents
   a case where encryption services are provided by the AC.
Top   ToC   RFC5416 - Page 9
             Client                      WTP                         AC

                      Beacon
             <-----------------------------
                   Probe Request
             ----------------------------( - )------------------------->
                   Probe Response
             <-----------------------------
                              802.11 AUTH/Association
             <--------------------------------------------------------->
                                        Station Configuration Request
                                          [Add Station (Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE
                                          802.11 Session Key(Flag=A)]
                                            <-------------------------->
                    802.1X Authentication & 802.11 Key Exchange
             <--------------------------------------------------------->
                                        Station Configuration Request
                                          [Add Station(Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE 802.11
                                          Station Session Key(Flag=C)]
                                            <-------------------------->
                               802.11 Action Frames
             <--------------------------------------------------------->
                                   802.11 DATA (1)
             <---------------------------( - )------------------------->

                     Figure 2: Split MAC Message Flow

   Figure 2 provides an illustration of the division of labor in a Split
   MAC architecture.  In this example, a WLAN has been created that is
   configured for IEEE 802.11, using 802.1X-based end user
   authentication and Advanced Encryption Standard-Counter Mode with
   CBC-MAC Protocol (AES-CCMP) link layer encryption (CCMP, see
   [FIPS.197.2001]).  The following process occurs:

   o  The WTP generates the IEEE 802.11 Beacon frames, using information
      provided to it through the IEEE 802.11 Add WLAN (see Section 6.1)
      message element, including the Robust Security Network Information
      Element (RSNIE), which indicates support of 802.1X and AES-CCMP.

   o  The WTP processes the Probe Request frame and responds with a
      corresponding Probe Response frame.  The Probe Request frame is
      then forwarded to the AC for optional processing.
Top   ToC   RFC5416 - Page 10
   o  The WTP forwards the IEEEE 802.11 Authentication and Association
      frames to the AC, which is responsible for responding to the
      client.

   o  Once the association is complete, the AC transmits a Station
      Configuration Request message, which includes an Add Station
      message element, to the WTP (see Section 4.6.8 in [RFC5415]).  In
      the above example, the WLAN was configured for IEEE 802.1X, and
      therefore the IEEE 802.11 Station Session Key is included with the
      flag field's 'A' bit set.

   o  If the WTP is providing encryption/decryption services, once the
      client has completed the IEEE 802.11 key exchange, the AC
      transmits another Station Configuration Request message, which
      includes:

      -  An Add Station message element.

      -  An IEEE 802.11 Add Station message element, which includes the
         WLAN Identifier with which the station has associated.

      -  An IEEE 802.11 Station Session Key message element, which
         includes the pairwise encryption key.

      -  An IEEE 802.11 Information Element message element, which
         includes the Robust Security Network Information Element
         (RSNIE) to the WTP, stating the security policy to enforce for
         the client (in this case AES-CCMP).

   o  If the WTP is providing encryption/decryption services, once the
      client has completed the IEEE 802.11 key exchange, the AC
      transmits another Station Configuration Request message, which
      includes:

      -  An Add Station message element.

      -  An IEEE 802.11 Add Station message element, which includes the
         WLAN Identifier with which the station has associated.

      -  An IEEE 802.11 Station Session Key message element, which
         includes the pairwise encryption key.

      -  An IEEE 802.11 Information Element message element, which
         includes the Robust Security Network Information Element
         (RSNIE) to the WTP, stating the security policy to enforce for
         the client (in this case AES-CCMP).
Top   ToC   RFC5416 - Page 11
   o  If the AC is providing encryption/decryption services, once the
      client has completed the IEEE 802.11 key exchange, the AC
      transmits another Station Configuration Request message, which
      includes:

      -  An Add Station message element.

      -  An IEEE 802.11 Add Station message element, which includes the
         WLAN Identifier with which the station has associated.

      -  An IEEE 802.11 Station Session Key message element with the
         flag field's 'C' bit enabled (indicating that the AC will
         provide crypto services).

   o  The WTP forwards any IEEE 802.11 Management Action frames received
      to the AC.

   o  All IEEE 802.11 station data frames are tunneled between the WTP
      and the AC.

   Note that during the EAP over LAN (EAPOL)-Key exchange between the
   Station and the AC, the Receive Sequence Counter (RSC) field for the
   Group Key (GTK) needs to be included in the frame.  The value of zero
   (0) is used by the AC during this exchange.  Additional details are
   available in Section 9.1.

   The WTP SHALL include the IEEE 802.11 MAC header contents in all
   frames transmitted to the AC.

   When 802.11 encryption/decryption is performed at the WTP, the WTP
   MUST decrypt the uplink frames, MUST set the Protected Frame field to
   0, and MUST make the frame format consistent with that of an
   unprotected 802.11 frame prior to transmitting the frames to the AC.
   The fields added to an 802.11 protected frame (i.e., Initialization
   Vector/Extended Initialization Vector (IV/EIV), Message Integrity
   Code (MIC), and Integrity Check Value (ICV)) MUST be stripped off
   prior to transmission from the WTP to AC.  For downlink frames, the
   Protected Frame field MUST be set to 0 by the AC as the frame being
   sent is unencrypted.  The WTP MUST apply the required protection
   policy for the WLAN, and set the Protected Frame field on
   transmission over the air.  The Protected Frame field always needs to
   accurately indicate the status of the 802.11 frame that is carrying
   it.

   When 802.11 encryption/decryption is performed at the AC, the WTP
   SHALL NOT decrypt the uplink frames prior to transmitting the frames
   to the AC.  The AC and WTP SHALL populate the IEEE 802.11 MAC header
   fields as described in Figure 3.
Top   ToC   RFC5416 - Page 12
           MAC header field        Location
                   Frame Control:
                           Version         AC
                           ToDS            AC
                           FromDS          AC
                           Type            AC
                           SubType         AC
                           MoreFrag        WTP/AC
                           Retry           WTP
                           Pwr Mgmt        -
                           MoreData        WTP
                           Protected       WTP/AC
                           Order           AC
                   Duration:           WTP
                   Address 1:          AC
                   Address 2:          AC
                   Address 3:          AC
                   Sequence Ctrl:      WTP
                   Address 4:          AC
                   QoS Control:        AC
                   Frame Body:         AC
                   FCS:                WTP

       Figure 3: Population of the IEEE 802.11 MAC Header Fields for
                              Downlink Frames

   When 802.11 encryption/decryption is performed at the AC, the
   MoreFrag bit is populated at the AC.  The Pwr Mgmt bit is not
   applicable to downlink frames, and is set to 0.  Note that the Frame
   Check Sequence (FCS) field is not included in 802.11 frames exchanged
   between the WTP and the AC.  Upon sending data frames to the AC, the
   WTP is responsible for validating and stripping the FCS field.  Upon
   receiving data frames from the AC, the WTP is responsible for adding
   the FCS field, and populating the field as described in
   [IEEE.802-11.2007].

   Note that when the WTP tunnels data packets to the AC (and vice
   versa), the CAPWAP protocol does not guarantee in-order delivery.
   When the protocol being transported over IEEE 802.11 is IP, out-of-
   order delivery is not an issue as IP has no such requirements.
   However, implementers need to be aware of this protocol
   characteristic before deciding to use CAPWAP.

2.2.2. Local MAC

This section shows the division of labor between the WTP and the AC in a Local MAC architecture. Figure 4 shows the separation of functionality among CAPWAP components.
Top   ToC   RFC5416 - Page 13
        Function                               Location
            Distribution Service                      WTP/AC
            Integration Service                       WTP
            Beacon Generation                         WTP
            Probe Response Generation                 WTP
            Power Mgmt/Packet Buffering               WTP
            Fragmentation/Defragmentation             WTP
            Assoc/Disassoc/Reassoc                    WTP/AC

       IEEE 802.11 QoS
            Classifying                               WTP
            Scheduling                                WTP
            Queuing                                   WTP

       IEEE 802.11 RSN
            IEEE 802.1X/EAP                           AC
            RSNA Key Management                       AC
            IEEE 802.11 Encryption/Decryption         WTP

      Figure 4: Mapping of 802.11 Functions for Local AP Architecture

   In the Local MAC mode, the integration service exists on the WTP,
   while the distribution service MAY reside on either the WTP or the
   AC.  When it resides on the AC, station-generated frames are not
   forwarded to the AC in their native format, but encapsulated as 802.3
   frames.

   While the MAC is terminated on the WTP, it is necessary for the AC to
   be aware of mobility events within the WTPs.  Thus, the WTP MUST
   forward the IEEE 802.11 Association Request frames to the AC.  The AC
   MAY reply with a failed Association Response frame if it deems it
   necessary, and upon receipt of a failed Association Response frame
   from the AC, the WTP MUST send a Disassociation frame to the station.

   The IEEE 802.1X [IEEE.802-1X.2004], EAP, and IEEE RSNA Key Management
   [IEEE.802-11.2007] functions reside in the AC.  Therefore, the WTP
   MUST forward all IEEE 802.1X, EAP, and RSNA Key Management frames to
   the AC and forward the corresponding responses to the station.  This
   implies that the AAA client also resides on the AC.

   Note that in the following figure, the use of '( - )' indicates that
   processing of the frames is done on the WTP.
Top   ToC   RFC5416 - Page 14
             Client                      WTP                         AC

                      Beacon
             <-----------------------------
                       Probe
             <---------------------------->
                        802.11 AUTH
             <-----------------------------
                                 802.11 Association
             <---------------------------( - )------------------------->
                                        Station Configuration Request
                                          [Add Station (Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE
                                          802.11 Session Key(Flag=A)]
                                            <-------------------------->
                    802.1X Authentication & 802.11 Key Exchange
             <--------------------------------------------------------->
                                        Station Configuration Request
                                          [Add Station(Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE 802.11
                                          Station session Key (Key=x),
                                          IEEE 802.11 Information
                                          Element(RSNIE(Pairwise
                                          Cipher=CCMP))]
                                            <-------------------------->
                               802.11 Action Frames
             <--------------------------------------------------------->
                     802.11 DATA
             <----------------------------->

                     Figure 5: Local MAC Message Flow

   Figure 5 provides an illustration of the division of labor in a Local
   MAC architecture.  In this example, a WLAN that is configured for
   IEEE 802.11 has been created using AES-CCMP for privacy.  The
   following process occurs:

   o  The WTP generates the IEEE 802.11 Beacon frames, using information
      provided to it through the Add WLAN (see Section 6.1) message
      element.

   o  The WTP processes a Probe Request frame and responds with a
      corresponding Probe Response frame.

   o  The WTP forwards the IEEE 802.11 Authentication and Association
      frames to the AC.
Top   ToC   RFC5416 - Page 15
   o  Once the association is complete, the AC transmits a Station
      Configuration Request message, which includes the Add Station
      message element, to the WTP (see Section 4.6.8 in [RFC5415]).  In
      the above example, the WLAN was configured for IEEE 802.1X, and
      therefore the IEEE 802.11 Station Session Key is included with the
      flag field's 'A' bit set.

   o  The WTP forwards all IEEE 802.1X and IEEE 802.11 key exchange
      messages to the AC for processing.

   o  The AC transmits another Station Configuration Request message,
      which includes:

      -  An Add Station message element, which MAY include a Virtual LAN
         (VLAN) [IEEE.802-1Q.2005] name, which when present is used by
         the WTP to identify the VLAN on which the user's data frames
         are to be bridged.

      -  An IEEE 802.11 Add Station message element, which includes the
         WLAN Identifier with which the station has associated.

      -  An IEEE 802.11 Station Session Key message element, which
         includes the pairwise encryption key.

      -  An IEEE 802.11 Information Element message element, which
         includes the RSNIE to the WTP, stating the security policy to
         enforce for the client (in this case AES-CCMP).

   o  The WTP forwards any IEEE 802.11 Management Action frames received
      to the AC.

   o  The WTP MAY locally bridge client data frames (and provide the
      necessary encryption and decryption services).  The WTP MAY also
      tunnel client data frames to the AC, using 802.3 frame tunnel mode
      or 802.11 frame tunnel mode.

2.3. Roaming Behavior

This section expands upon the examples provided in the previous section, and describes how the CAPWAP control protocol is used to provide secure roaming. Once a client has successfully associated with the network in a secure fashion, it is likely to attempt to roam to another WTP. Figure 6 shows an example of a currently associated station moving from its "Old WTP" to a "New WTP". The figure is valid for multiple different security policies, including IEEE 802.1X and Wireless Protected Access (WPA) or Wireless Protected Access 2 (WPA2) [WPA].
Top   ToC   RFC5416 - Page 16
   In the event that key caching was employed, the 802.1X Authentication
   step would be eliminated.  Note that the example represents one where
   crypto services are provided by the WTP, so in a case where the AC
   provided this function the last Station Configuration Request would
   be different.

            Client              Old WTP            New WTP           AC

                          Association Request/Response
             <--------------------------------------( - )-------------->
                                        Station Configuration Request
                                          [Add Station (Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE
                                          802.11 Session Key(Flag=A)]
                                                      <---------------->
             802.1X Authentication (if no key cache entry exists)
             <--------------------------------------( - )-------------->
                           802.11 4-way Key Exchange
             <--------------------------------------( - )-------------->
                                Station Configuration Request
                                  [Delete Station]
                                    <---------------------------------->
                                        Station Configuration Request
                                          [Add Station(Station MAC
                                          Address), IEEE 802.11 Add
                                          Station (WLAN ID), IEEE 802.11
                                          Station session Key (Key=x),
                                          IEEE 802.11 Information
                                          Element(RSNIE(Pairwise
                                          Cipher=CCMP))]
                                                      <---------------->

                     Figure 6: Client Roaming Example

2.4. Group Key Refresh

Periodically, the Group Key (GTK) for the BSS needs to be updated. The AC uses an EAPOL-Key frame to update the group key for each STA in the BSS. While the AC is updating the GTK, each Layer 2 (L2) broadcast frame transmitted to the BSS needs to be duplicated and transmitted using both the current GTK and the new GTK. Once the GTK update process has completed, broadcast frames transmitted to the BSS will be encrypted using the new GTK. In the case of Split MAC, the AC needs to duplicate all broadcast packets and update the key index so that the packet is transmitted using both the current and new GTK to ensure that all STAs in the BSS
Top   ToC   RFC5416 - Page 17
   receive the broadcast frames.  In the case of Local MAC, the WTP
   needs to duplicate and transmit broadcast frames using the
   appropriate index to ensure that all STAs in the BSS continue to
   receive broadcast frames.

   The Group Key update procedure is shown in the following figure.  The
   AC will signal the update to the GTK using an IEEE 802.11
   Configuration Request message, including an IEEE 802.11 Update WLAN
   message element with the new GTK, its index, the Transmit Sequence
   Counter (TSC) for the Group Key and the Key Status set to 3 (begin
   GTK update).  The AC will then begin updating the GTK for each STA.
   During this time, the AC (for Split MAC) or WTP (for Local MAC) MUST
   duplicate broadcast packets and transmit them encrypted with both the
   current and new GTK.  When the AC has completed the GTK update to all
   STAs in the BSS, the AC MUST transmit an IEEE 802.11 Configuration
   Request message including an IEEE 802.11 Update WLAN message element
   containing the new GTK, its index, and the Key Status set to 4 (GTK
   update complete).

        Client           WTP                                          AC

                         IEEE 802.11 WLAN Configuration Request [Update
                           WLAN (GTK, GTK Index, GTK Start,
                           Group TSC) ]
                         <--------------------------------------------
                               802.1X EAPoL (GTK Message 1)
        <-------------( - )-------------------------------------------
                               802.1X EAPoL (GTK Message 2)
        -------------( - )------------------------------------------->
                         IEEE 802.11 WLAN Configuration Request [ Update
                           WLAN (GTK Index, GTK Complete) ]
                         <--------------------------------------------

                   Figure 7: Group Key Update Procedure

2.5. BSSID to WLAN ID Mapping

The CAPWAP protocol binding enables the WTP to assign BSSIDs upon creation of a WLAN (see Section 6.1). While manufacturers are free to assign BSSIDs using any arbitrary mechanism, it is advised that where possible the BSSIDs are assigned as a contiguous block. When assigned as a block, implementations can still assign any of the available BSSIDs to any WLAN. One possible method is for the WTP to assign the address using the following algorithm: base BSSID address + WLAN ID.
Top   ToC   RFC5416 - Page 18
   The WTP communicates the maximum number of BSSIDs that it supports
   during configuration via the IEEE 802.11 WTP WLAN Radio Configuration
   message element (see Section 6.23).

2.6. CAPWAP Data Channel QoS Behavior

The CAPWAP IEEE 802.11 binding specification provides procedures to allow for the WTP to enforce Quality of Service on IEEE 802.11 Data Frames and MAC Management messages.

2.6.1. IEEE 802.11 Data Frames

When the WLAN is created on the WTP, a default Quality of Service policy is established through the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). This default policy will cause the WTP to use the default QoS values for any station associated with the WLAN in question. The AC MAY also override the policy for a given station by sending the IEEE 802.11 Update Station QoS message element (see Section 6.20), known as a station-specific QoS policy. Beyond the default, and per station QoS policy, the IEEE 802.11 protocol also allows a station to request special QoS treatment for a specific flow through the Traffic Specification (TSPEC) Information Elements found in the IEEE 802.11-2007's QoS Action Frame. Alternatively, stations MAY also use the WiFi Alliance's WMM specification instead to request QoS treatment for a flow (see [WMM]). This requires the WTP to observe the Status Code in the IEEE 802.11-2007 and WMM QoS Action Add Traffic System (ADDTS) responses from the AC, and provide the services requested in the TSPEC Information Element. Similarly, the WTP MUST observe the Reason Code Information Element in the IEEE 802.11-2007 and WMM QoS Action DELTS responses from the AC by removing the policy associated with the TSPEC. The IEEE 802.11 WTP Quality of Service message element's Tagging Policy field indicates how the packets are to be tagged, known as the Tagging Policy. There are five bits defined, two of which are used to indicate the type of QoS to be used by the WTP. The first is the 'P' bit, which is set to inform the WTP it is to use the 802.1p QoS mechanism. When set, the 'Q' bit is used to inform the WTP which 802.1p priority values it is to use. The 'D' bit is set to inform the WTP it is to use the Differentiated Services Code Point (DSCP) QoS mechanism. When set, the 'I' and 'O' bits are used to inform the WTP which values it is to use in the inner header, in the station's original packet, or the outer header, the latter of which is only valid when tunneling is enabled.
Top   ToC   RFC5416 - Page 19
   When an IEEE 802.11 Update Station QoS message element is received,
   while the specific 802.1p priority or DSCP values may change for a
   given station, known as the station specific policy, the original
   Tagging Policy (the use of the five bits) remains the same.

   The use of the DSCP and 802.1p QoS mechanisms are not mutually
   exclusive.  An AC MAY request that a WTP use none, one, or both types
   of QoS mechanisms at the same time.

2.6.1.1. 802.1p Support
The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements include the "802.1p Tag" field, which is the 802.1p priority value. This value is used by the WTP by adding an 802.1Q header (see [IEEE.802-1Q.2005]) with the priority field set according to the policy provided. Note that this tagging is only valid for interfaces that support 802.1p. The actual treatment does not change for either Split or Local MAC modes, or when tunneling is used. The only exception is when tunneling is used, the 802.1Q header is added to the outer packet (tunneled) header. The IEEE 802.11 standard does not permit the station's packet to include an 802.1Q header. Instead, the QoS mechanisms defined in the IEEE 802.11 standard are used by stations to mark a packet's priority. When the 'P' bit is set in the Tagging Policy, the 'Q' bit has the following behavior: Q=1: The WTP marks the priority field in the 802.1Q header to either the default or the station-specific 802.1p policy. Q=0: The WTP marks the priority field in the 802.1Q header to the value found in the User Priority field of the QoS Control field of the IEEE 802.11 header. If the QoS Control field is not present in the IEEE 802.11 header, then the behavior described under 'Q=1' is used.
2.6.1.2. DSCP Support
The IEEE 802.11 WTP Quality of Service and IEEE 802.11 Update Station QoS message elements also provide a "DSCP Tag", which is used by the WTP when the 'D' bit is set to mark the DSCP field of both the IPv4 and IPv6 headers (see [RFC2474]). When DSCP is used, the WTP marks the inner packet (the original packet received by the station) when the 'I' bit is set. Similarly, the WTP marks the outer packet (tunnel header's DSCP field) when the 'O' bit is set. When the 'D' bit is set, the treatment of the packet differs based on whether the WTP is tunneling the station's packets to the AC. Tunneling does not occur in a Local MAC mode when the AC has
Top   ToC   RFC5416 - Page 20
   communicated that tunneling is not required, as part of the IEEE
   802.11 Add WLAN message element, see Section 6.1.  In the case where
   tunneling is not used, the 'I' and 'O' bits have the following
   behaviors:

   O=1:   This option is invalid when tunneling is not enabled for
          station data frames.

   O=0:   This option is invalid when tunneling is not enabled for
          station data frames.

   I=1:   The WTP sets the DSCP field in the station's packet to either
          the default policy or the station-specific policy if one
          exists.

   I=0:   The WTP MUST NOT modify the DSCP field in the station's
          packet.

   For Split MAC mode, or Local MAC with tunneling enabled, the WTP
   needs to contend with both the inner packet (the station's original
   packet) as well as the tunnel header (added by the WTP).  In this
   mode of operation, the bits are treated as follows:

   O=1:   The WTP sets the DSCP field in the tunnel header to either the
          default policy or the station specific policy if one exists.

   O=0:   The WTP sets the DSCP field in the tunnel header to the value
          found in the inner packet's DSCP field.  If encryption
          services are provided by the AC (see Section 6.15), the packet
          is encrypted; therefore, the WTP cannot access the inner DSCP
          field, in which case it uses the behavior described when the
          'O' bit is set.  This occurs also if the inner packet is not
          IPv4 or IPv6, and thus does not have a DSCP field.

   I=1:   The WTP sets the DSCP field in the station's packet to either
          the default policy or the station-specific policy if one
          exists.  If encryption services are provided by the AC (see
          Section 6.15), the packet is encrypted; therefore, the WTP
          cannot access the inner DSCP field, in which case it uses the
          behavior described when the 'I' bit is not set.  This occurs
          also if the inner packet is not IPv4 or IPv6, and thus does
          not have a DSCP field.

   I=0:   The WTP MUST NOT modify the DSCP field in the station's
          packet.
Top   ToC   RFC5416 - Page 21
   The CAPWAP protocol supports the Explicit Congestion Notification
   (ECN) bits [RFC3168].  Additional details on ECN support can be found
   in [RFC5415].

2.6.2. IEEE 802.11 MAC Management Messages

It is recommended that IEEE 802.11 MAC Management frames be sent by both the AC and the WTP with appropriate Quality of Service values, listed below, to ensure that congestion in the network minimizes occurrences of packet loss. Note that the QoS Mechanism specified in the Tagging Policy is used as specified by the AC in the IEEE 802.11 WTP Quality of Service message element (see Section 6.22). However, the station-specific policy is not used for IEEE 802.11 MAC Management frames. 802.1p: The precedence value of 7 (decimal) SHOULD be used for all IEEE 802.11 MAC management frames, except for Probe Requests, which SHOULD use 4. DSCP: All IEEE 802.11 MAC management frames SHOULD use the CS6 per- hop behavior (see [RFC2474]), while IEEE 802.11 Probe Requests should use the Low Drop Assured Forwarding per-hop behavior (see [RFC3246]).

2.7. Run State Operation

The Run state is the normal state of operation for the CAPWAP protocol in both the WTP and the AC. When the WTP receives a WLAN Configuration Request message (see Section 3.1), it MUST respond with a WLAN Configuration Response message (see Section 3.2), and it remains in the Run state. When the AC sends a WLAN Configuration Request message (see Section 3.1) or receives the corresponding WLAN Configuration Response message (see Section 3.2) from the WTP, it remains in the Run state.


(page 21 continued on part 2)

Next Section