<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc5415 PUBLIC '' 
      'reference.RFC.5415.xml'>
    <!ENTITY rfc5416 PUBLIC '' 
      'reference.RFC.5416.xml'>
    <!ENTITY rfc5226 PUBLIC '' 
      'reference.RFC.5226.xml'>
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?> 
<?rfc subcompact="no" ?>

<rfc category="std" ipr="trust200902" number="7494" submissionType="IETF" consensus="yes">


<front>
<title abbrev="CAPWAP MAC Profile">IEEE 802.11 Medium Access Control (MAC) Profile for Control and Provisioning of Wireless Access Points (CAPWAP) </title>

<author initials="C." surname="Shao" fullname="Chunju Shao">
 <organization>China Mobile</organization>
 <address>
  <postal>
   <street>No.32 Xuanwumen West Street</street>
   <city>Beijing  100053</city>
   <country>China</country>
  </postal>
  <email>shaochunju@chinamobile.com</email>
 </address>
</author>

<author initials="H." surname="Deng" fullname="Hui Deng">
 <organization>China Mobile</organization> 
 <address>
  <postal>
   <street>No.32 Xuanwumen West Street</street>
   <city>Beijing  100053</city>
   <country>China</country>
  </postal>
  <email>denghui@chinamobile.com</email>
 </address>
</author>

<author fullname="Rajesh S. Pazhyannur" initials="R.P" surname="Pazhyannur">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose, CA 95134</city>
          <region/>
          <code/>
          <country>United States</country>
        </postal>
        <phone/>
        <facsimile/>
        <email>rpazhyan@cisco.com</email>
        <uri/>
      </address>
</author>
<author initials="F." surname="Bari" fullname="Farooq Bari">
 <organization>AT&amp;T</organization> 
 <address>
  <postal>
   <street>7277 164th Ave NE</street>
   <city>Redmond, WA 98052</city>
   <country>United States</country>
  </postal>
  <email>farooq.bari@att.com</email>
 </address>
</author>

<author initials="R." surname="Zhang" fullname="Rong Zhang">
 <organization>China Telecom</organization> 
 <address>
  <postal>
   <street> No.109 Zhongshandadao avenue</street>
   <city>Guangzhou  510630</city>
   <country>China</country>
  </postal>
  <email>zhangr@gsta.com</email>
 </address>
</author>

<author initials="S." surname="Matsushima" fullname="Satoru Matsushima">
 <organization>SoftBank Telecom</organization> 
 <address>
  <postal>
   <street>1-9-1 Higashi-Shinbashi, Munato-ku</street>
   <city>Tokyo</city>
   <country>Japan</country>
  </postal>
  <email>satoru.matsushima@g.softbank.co.jp</email>
 </address>
</author>


<date month="March" year="2015"/>

<area>OPS</area><workgroup></workgroup>

<abstract>

 	<t> 
	 The Control and Provisioning of Wireless Access Points (CAPWAP) protocol binding for IEEE 802.11 defines two Medium Access
	   Control (MAC) modes for IEEE 802.11 Wireless Transmission Points (WTPs): Split and Local MAC. In the Split MAC mode, the partitioning of encryption/decryption functions is not 
	   clearly defined.  In the Split MAC mode description, IEEE
	   802.11 encryption is specified as located in either the Access Controller (AC) or the WTP,
	   with no clear way for the AC to inform the WTP of where the encryption functionality should be located.
	   This leads to interoperability issues, especially when the
	   AC and WTP come from different vendors.
           To prevent interoperability issues, this
	   specification defines an IEEE 802.11 MAC Profile message element in which each profile
	   specifies an unambiguous division of encryption functionality between the WTP
	   and AC.
	</t>
 </abstract>
</front>

<middle>

<section anchor="intro" title="Introduction">
 <t> 
	 The CAPWAP protocol supports two MAC modes of operation: Split and 
	 Local MAC, as described in <xref target = "RFC5415" /> and
	 <xref target = "RFC5416" />. 
	 However, there are MAC functions that have not been clearly defined. 
	 For example, IEEE 802.11 <xref target="IEEE.802.11"/> encryption is specified as located 
	 in either the AC or the WTP 
	 with no clear way to negotiate where it should be located.  
	 Because different vendors have different definitions of the MAC mode, many MAC-layer functions are 
	 mapped differently 
	 to either the WTP or the AC by different vendors. Therefore, depending upon the vendor, the operators in their 
	 deployments have to perform different configurations based on implementation of the two modes by their vendor.  
	 If there is no clear specification, then operators will experience interoperability issues with WTPs and ACs from different vendors.
 </t>
  <t>
	  <xref target="fig.functions"/> from  <xref target="RFC5416"/> illustrates how some functions are processed in different places 
	  in the Local MAC and Split MAC mode.  Specifically, note that in the Split MAC mode, the IEEE 802.11 encryption/decryption is specified as WTP/AC, implying that 
	  it could be at either location. This is not an issue with Local MAC because encryption is always at the WTP. 
  </t>
 
  <figure anchor="fig.functions" title="Functions in Local MAC and Split MAC">
    <artwork><![CDATA[ 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Functions                  | Local MAC | Split MAC | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Distribution Service     |  WTP/AC   |     AC    |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Integration Service      |   WTP     |     AC    |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Beacon Generation        |   WTP     |     WTP   |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Probe Response Generation|   WTP     |     WTP   |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function    |Power Mgmt/              |   WTP     |     WTP   |
+             |Packet Buffering         |           |           |
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Fragmentation/           |   WTP     |    WTP/AC |
+             |Defragmentation          |           |           |
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Assoc/Disassoc/Reassoc   |  WTP/AC   |     AC    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Classifying              |   WTP     |     AC    |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 QoS  |Scheduling               |   WTP     |    WTP/AC |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Queuing                  |   WTP     |    WTP    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.1X/EAP          |   AC      |    AC     |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 RSN  |RSNA Key Management      |   AC      |    AC     |
+  (WPA2)     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.11              |   WTP     |    WTP/AC |
+             |Encryption/Decryption    |           |           |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note:
  RSN - Robust Security Network 
  RSNA - Robust Security Network Association
  WPA2 - Wi-Fi Protected Access 2

]]></artwork>
  </figure>

 <t>
	 To solve this problem, this specification introduces the IEEE 802.11 MAC Profile. The IEEE 802.11 MAC Profile unambiguously specifies
	 where the various MAC functionalities should be located. 
 </t>
</section>


<section title="IEEE MAC Profile Descriptions">
  <t>
	  A IEEE 802.11 MAC Profile refers to a description of how  
	  the MAC functionality is split between the WTP and AC shown in <xref target="fig.functions"/>. 
  </t>

<section anchor = "hybridmac-WTP" title="Split MAC with WTP Encryption">
	  <t> 
		  The functional split for the Split MAC with WTP encryption is provided in <xref target="fig.hybridmac"/>. 
	  This profile
	  is similar to the Split MAC description in <xref target="RFC5416" />, 
	  except that IEEE 802.11 
	  encryption/decryption 
	  is at the WTP. Note that 
	  fragmentation is always done at the same entity as the encryption. 
	  Consequently, in this profile fragmentation/defragmentation is also 
	  done only at the WTP.
	  Note that scheduling functionality is denoted as WTP/AC. As explained
	  in <xref target="RFC5416"/>, this means 
	  that the admission control component of IEEE 802.11 resides on the
          AC; the real-time scheduling and queuing functions are on the WTP.
  </t>


  <figure anchor="fig.hybridmac" title="Functions in Split MAC with WTP Encryption">
    <artwork><![CDATA[ 
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Functions                  | Profile   | 
|                                       |    0      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Distribution Service     |   AC      | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Integration Service      |   AC      | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Beacon Generation        |   WTP     | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Probe Response Generation|   WTP     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function    |Power Mgmt/              |   WTP     |
+             |Packet Buffering        |           | 
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Fragmentation/           |   WTP     |
+             |Defragmentation          |           |
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Assoc/Disassoc/Reassoc   |   AC      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Classifying              |   AC      |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 QoS  |Scheduling               |   WTP/AC  |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Queuing                  |   WTP     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.1X/EAP          |   AC      |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 RSN  |RSNA Key Management      |   AC      |
+  (WPA2)     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.11              |   WTP     |
+             |Encryption/Decryption    |           |           
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note:
EAP - Extensible Authentication Protocol

]]></artwork>
  </figure>
</section>

<section anchor = "hybridmac-AC" title="Split MAC with AC Encryption">
	  <t> 
		  The functional split for the Split MAC with AC encryption is provided in <xref target="fig.hybridmac-ac"/>. 
	  This profile
	  is similar to the Split MAC in <xref target="RFC5416" />, except that IEEE 802.11 
	  encryption/decryption 
	  is at the AC. Since 
	  fragmentation is always done at the same entity as the encryption, 
	  in this profile, AC does fragmentation/defragmentation.
  </t>

  <figure anchor="fig.hybridmac-ac" title="Functions in Split MAC with AC encryption">
    <artwork><![CDATA[ 
 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Functions                  | Profile   | 
|                                       |    1      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Distribution Service     |   AC      | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Integration Service      |   AC      | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Beacon Generation        |   WTP     | 
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Probe Response Generation|   WTP     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function    |Power Mgmt/              |   WTP     |
+             |Packet Buffering         |           | 
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Fragmentation/           |   AC      |
+             |Defragmentation          |           |
|             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Assoc/Disassoc/Reassoc   |   AC      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Classifying              |   AC      |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 QoS  |Scheduling               |   WTP     |
+             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |Queuing                  |   WTP     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.1X/EAP          |   AC      |
+   IEEE      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11 RSN  |RSNA Key Management      |   AC      |
+  (WPA2)     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             |IEEE 802.11              |   AC      |
+             |Encryption/Decryption    |           |           
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
  </figure>
</section>

<section title="IEEE 802.11 MAC Profile Frame Exchange">
  <t>
   An example of message exchange using the IEEE 802.11 MAC Profile message element is shown in <xref target="fig.hybridframes"/>.  The WTP informs the AC of the various MAC Profiles it supports. 
	  This happens in either a Discovery Request message or the Join Request message. The AC determines 
	  the appropriate profile and configures the WTP with the profile while configuring the WLAN.
  </t>


  <figure anchor="fig.hybridframes" title="Message Exchange for Negotiating MAC Profiles">
    <artwork><![CDATA[ 

    +-+-+-+-+-+-+                             +-+-+-+-+-+-+
    |    WTP    |                             |    AC     | 
    +-+-+-+-+-+-+                             +-+-+-+-+-+-+
          |Join Request[Supported IEEE 802.11       |
          |       MAC Profiles   ]                  | 
          |---------------------------------------->|
          |                                         | 
          |Join Response                            |
          |<----------------------------------------|
          |                                         | 
          |IEEE 802.11 WLAN Config. Request [       |
          | IEEE 802.11 Add WLAN,                   |
          | IEEE 802.11 MAC Profile                 |
          |   ]                                     | 
          |<----------------------------------------|
          |                                         | 
          |IEEE 802.11 WLAN Config. Response        |
          |---------------------------------------->|
          
          ]]></artwork>
  </figure>
</section>
</section>

<section title="MAC Profile Message Element Definitions">
<section anchor ="supportedMacProfile" title="IEEE 802.11 Supported MAC Profiles">
<t>
	The IEEE 802.11 Supported MAC Profile message element allows the WTP to communicate the profiles it 
	supports. 
The Discovery Request message, Primary Discovery Request
message, and Join Request message may include one such message
element. 
</t>

<figure anchor="format1"  title="IEEE 802.11 Supported MAC Profiles">
<artwork><![CDATA[
        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_Profiles  |  Profile_1    |   Profile_[2..N]..   
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
        ]]></artwork>
</figure>
<t> <list style ="symbols">
		<t> Type:  1060 for IEEE 802.11 Supported MAC Profiles </t>

		<t> Num_Profiles >=1:   This refers to the number of profiles present in this message element. There must be at least one profile. 
	       	</t>

		<t> Profile:  Each profile is identified by a value specified in <xref target = "macProfile" />. 
		      
                </t>
 </list>
 </t>
</section>
<section anchor = "macProfile" title="IEEE 802.11 MAC Profile">
<t>
	The IEEE 802.11 MAC Profile message element allows the AC to select a profile.
	This message element may be provided along with the IEEE 802.11 ADD WLAN message
	element while configuring a WLAN on the WTP.
</t>


<figure anchor="format2"  title="IEEE 802.11 MAC Profile">
<artwork><![CDATA[
                                       
        0 1 2 3 4 5 6 7  
       +=+-+-+-+-+-+-+-+
       |  Profile      |   
       +-+-+-+-+-+-+-+-+
        ]]></artwork>
</figure>
<t> <list style ="symbols">
		<t> Type:  1061 for IEEE 802.11 MAC Profile </t>

		<t> Profile:  The profile is identified by a value as given below
		     <list style = "symbols">				
			     <t> 0: This refers to the IEEE 802.11 Split MAC Profile with WTP encryption </t> 
			     <t> 1: This refers to the IEEE 802.11 Split MAC Profile with AC encryption  </t> 
	              </list> 
                </t>
 </list>
 </t>
</section>
</section>
<section anchor="security" title="Security Considerations">
	<t>
		This document does not introduce any new security risks compared to  <xref target="RFC5416"/>. The negotiation messages between the WTP and AC have origin authentication and data integrity. As a result, an attacker cannot interfere with the messages to force a less-secure mode choice. The security considerations described in  <xref target="RFC5416"/> apply here as well. </t>
</section>


<section title="IANA Considerations">
	<t>
		 The following IANA actions have been completed.
		<list style = "symbols" >
			<t> This specification defines two new message elements: IEEE 802.11 Supported MAC Profiles
			        (described in <xref target = "supportedMacProfile"/>)	
				and the IEEE 802.11 MAC Profile (described in <xref target = "macProfile"/>). 
				These elements have been registered in the existing "CAPWAP Message Element Type" registry, 
				defined in <xref target = "RFC5415" />. 
			
			        <figure>
                                <artwork><![CDATA[
           CAPWAP Protocol Message Element                Type Value 
           IEEE 802.11 Supported MAC Profiles              1060 
           IEEE 802.11 MAC Profile                         1061 
         ]]></artwork>
        </figure>
                </t>
		<t>
			The IEEE 802.11 Supported MAC Profiles message element and 
		        IEEE 802.11 MAC Profile message element include a Profile field	
			(as defined in <xref target = "macProfile"/>).  The Profile field in the IEEE 802.11 Supported MAC Profiles  
			denotes the MAC Profiles supported by the WTP.  The Profile field in the IEEE 802.11 MAC Profile denotes 
			the MAC Profile assigned to the WTP. The namespace for the field is 8 bits (0-255). This specification defines two values:
		       	zero (0) and one (1) as described below. The remaining values (2-255) are controlled and


			maintained by IANA, and the registration procedure is Expert Review <xref target="RFC5226"/>.
			IANA has created a new subregistry called "IEEE 802.11 Split
				      MAC Profile" under the existing registry
				"Control And Provisioning of Wireless Access Points (CAPWAP) Parameters".  The registry format is given below.

	        <figure>
                 <artwork><![CDATA[
            Profile                             Type Value  Reference 
            Split MAC with WTP encryption       0           RFC 7494
            Split MAC with AC encryption        1           RFC 7494
                 ]]></artwork>
                 </figure>	
		</t>
	    </list>
        </t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc5415;
&rfc5416;

 <reference anchor="IEEE.802.11" target="http://standards.ieee.org/about/get/802/802.11.html">
        <front>
          <title>
            IEEE Standard for
            Information Technology -
            Telecommunications and information
            exchange between systems -
            Local and metropolitan area networks -
            Specific requirements
            Part 11: Wireless LAN Medium Access Control (MAC)
            and Physical Layer (PHY) Specifications
          </title>
          <author><organization>IEEE</organization></author>
          <date year="2012" month="March" />
        </front>
        <seriesInfo name="IEEE Std" value="802.11-2012" />
      </reference>

</references>

<references title="Informative References">
&rfc5226;
</references>

<section title="Acknowledgments" numbered="no">
			
	 <t>The authors are grateful for extremely valuable suggestions from Dorothy Stanley in developing this 
	 specification. </t>
 <t>Guidance from the management team -- Melinda Shore, Scott Bradner, Chris Liljenstolpe, Benoit Claise, Joel Jaeggli, and Dan Romascanu -- is highly appreciated.</t>

  </section>

<section title="Contributors" numbered="no">
 <t> Yifan Chen &lt;chenyifan@chinamobile.com&gt;</t>
 <t> Naibao Zhou &lt;zhounaibao@chinamobile.com&gt;</t>
 </section>

</back>
</rfc>
