AP-AC接口标准化浅析

陈一帆，周伯慧，邵春菊，杨光

(中国移动通信集团研究院)

摘要:AP-AC通信接口的定义是瘦AP+AC结构下整个WLAN网络的一个关键问题，因此AP-AC接口的统一对WLAN网络的升级维护及未来的长期演进起着非常重要的作用。本文基于AP-AC接口开放的现状，分析了当前各厂商AP-AC接口实现机制的差异，最后给出了AP-AC接口开放需要完成的工作以及前景，为后续的接口标准化提供了一种可行性方案。

引言

随着WLAN技术的愈加成熟，传统的以胖AP为主要组成部分的自治型WLAN网络逐渐演变为以瘦AP+AC为架构的会聚型WLAN网络。在瘦AP+AC为架构的WLAN网络下，AP-AC间通信接口的定义成为整个会聚型网络的关键。国际标准化组织以及部分厂商为统一AP-AC的接口制定了一些规范，其中包括RFC系列的关于CAPWAP的规范。虽然CAPWAP规范定义了AP-AC之间的一部分通信机制以及CAPWAP隧道的具体结构，但是并没有明确功能的实现流程及实现位置。因此，各厂商的实现机制及AP-AC接口的定义千差万别，私有化的AP-AC接口不能及时满足日新月异的运营需求，网络的升级维护困难重重。因此，WLAN网络的大规模建设迫切需要将AP-AC接口进行统一。

本文从整个网络的演进入手，阐述瘦AP+AC架构的由来以及由此引申出来AP与AC之间接口规范的问题，系统分析了当前瘦AP+AC架构下两大主要MAC结构——Local MAC和Split MAC的主要差别以及各厂商对于这两大架构实现方式的差异和功能上的不同。通过对CAPWAP隧道建立机制的分析，在文章最后，提出了AP-AC接口开放的前景以及需要完成的工作。

一 AP-AC接口标准的由来

传统的WLAN网络主要是为企业或家庭内部移动用户的接入而组建的。仅基于这种需求，往往需要少数AP就可以满足。通常我们把基于这种情况而组建的AP称为胖AP。胖AP的结构特点是将WLAN的物理层、用户数据加密、用户认证、QoS、网络管理、漫游技术以及其他应用层的功能集于一身，因此它的功能全面但结构复杂。随着无线网络的发展，需要大量部署AP的地方越来越多，胖AP的弊端也越来越明显：

（1）WLAN建网需要对AP进行逐一配置，例如网关IP地址、SSID和加密认证方式等无线业务参数、信道和发射功率等射频参数管理、ACL和QoS等服务策略等，这些都会给用户带来很大的操作成本。

（2）管理AP时需要维护大量AP的IP地址列表，需要进行地址关系维护的工作量大。

（3）接入AP的边缘网络需要更改VLAN、ACL等配置以适应无线用户的接入，为了能够支持无缝漫游，需要在边缘网络上配置所有无线用户可能使用的VLAN和ACL。

（4）查看网络运行状况和用户统计、在先更改服务策略和安全策略设定时都需要逐一登陆到AP设备才能完成响应的操作。

（5）升级AP软件需要手动逐一对设备进行升级，对AP设备进行重配置时需要进行全网重配置。

因此，在2002年的时候，WLAN在企业等应用发展下出现了新的趋势，瘦（FIT）AP+AC的架构应运而生。

瘦AP+AC架构中无线控制器AC负责网络的接入控制、转发和统计、AP的配置监控、漫游管理、AP的网管代理以及安全控制等，瘦AP负责802.11报文的加解密、无线物理层PHY功能、RF空口的统计等功能。瘦AP+AC架构组网方式的优点有：

（1）瘦AP启动时自动从AC下载合适的设备配置信息，配置信息改动或更新时无需人工手动进行配置。

（2）瘦AP能够自动获取IP地址，自动发现可接入的AC，并对AC和瘦AP之间的网络拓扑不敏感。

（3）AC支持瘦AP的配置代理和查询代理，能够将用户对瘦AP的配置顺利传达到指定的瘦AP设备，同时可以查看瘦AP的状态和统计信息。

（4）AC支持下发最新版本软件到瘦AP，自动升级瘦AP。

在大规模组网部署应用的情况下，瘦AP+AC架构比胖AP架构具有方便集中管理、三层漫游、基于用户下发权限等优势，因此，瘦AP+AC更适合WLAN发展趋势。

在瘦AP+AC架构下，AP不能单独工作，需要与AC配合使用，因此AP和AC间需要有配套的通信协议可以让他们进行互联。最早，思科制定了首个AP-AC之间的隧道通信协议——LWAPP，接着，IETF为了解决各厂商AP-AC间隧道协议的不兼容问题，在2005年成立了CAPWAP工作组以标准化AP和AC间的隧道协议。表1为国际、国内各个标准化组织关于AP-AC间接口标准化的工作。

 

标准化组织		已定义协议	标准现状	推进分析
国际标准	IEEE	802.11	WLAN通用标准，原则上只涉及终端和AP间无线空口协议	暂无AP-AC接口定义相关工作组
		802.1X	用户接入网络的认证标准，在用户接入网络之前运行，工作于数据链路层
	3GPP	23.234	定义了WLAN子系统和核心网之间的各种接口	暂无AP-AC接口定义相关工作组
	IETF	CAPWAP	（Control And Provisioning of Wireless Access Points）AP-AC接口标准化协议	针对AP-AC接口进行了标准化，但缺乏细节定义，可考虑后续推进
		EAP	（Extensible Authentication Protocol）可扩展的鉴权协议，可配合802.1X进行鉴权认证	暂无AP-AC接口定义相关的工作组
国内标准	CCSA-行标	PWLAN	AP、AC松耦合的标准，没有引入额外的交互，与CAPWAP不兼容	CCSA暂无AP-AC接口相关的工作组；WAPI曾推动过该工作，但未形成标准发布
	WAPI-国标	系列国标	关注终端和AP直接相互认证、信道加密、目前没有任何AP-AC间的强相关标准

 

表1 国际国内各标准化组织关于AP-AC接口标准化推动工作

二．AP-AC接口开放现状

根据现网的组成情况来看（从2008年奥运会集采的设备到2010年集采设备），WLAN网络的架构已经逐渐转向以瘦AP+AC的架构为主的组网模式。虽然瘦AP+AC的WLAN架构已获众多厂商支持，但是由于CAPWAP协议所规定的关于AP-AC间接口开放框架性太强，各厂商具体实现各异，因此接口私有化的现象比较普遍，造成各厂商之间的AP-AC之间仍然不能有效互通。各厂商AP-AC接口的私有化，导致WLAN网络后续扩容对厂商依赖比较高，AC维护升级困难，以及比较难统一对各厂商AC业务处理能力的评估测试。

瘦AP+AC模式下的分布式WLAN网络主要有三种架构，分别为Local MAC架构、Split MAC架构和Remote MAC架构。这三种架构的主要区别如表2所示，考虑到现网的实际情况，Remote MAC往往不符合当前现网的配置，因此我们当前只考虑Local MAC和Split MAC这两种瘦AP+AC架构。

 

	Local MAC		Remote MAC		Split MAC
原理	802.3MAC	AC	802.3MAC	AC	802.3MAC	AC
			802.11MAC		802.11MAC非实时部分
	802.11MAC	AP	802.11PHY	AP	802.11MAC实时部分	AP
	802.11PHY				802.11PHY
	AP完成802.11帧向802.3的帧格式转变，CAPWAP作为隧道转发802.3数据帧		AP直接转发802.11数据帧，AC完成对802.11帧的处理		CAPWAP作为隧道直接转发所有非实时业务802.11数据帧，实时业务在AP处理
优势	1.功能划分清晰，低耦合 2.AP易实现胖、瘦一体化 3.数据可通过AP本地转发，也可通过AC集中转发		1.AP实现简单，硬件要求低		1.对AP的性能要求低 2.最大限度发挥AC、AP自身特点，认证管理等非实时功能由AC实现，利于进行集中管理；无线控制功能由AP实现，利于提高网络性能，减少延时
劣势	1.AP性能要求高：新的芯片已经解决性能问题 2.802.11原始信息丢失，防攻击能力下降		1.AC实现非常复杂 2.由于承载网传输延时，实时性无法保证		1.对AC性能要求高，管理AP数量会受到影响 2.分离MAC没有统一标准可循

表2 Local MAC、Split MAC和Remote MAC架构的主要区别

 

CAPWAP协议对Local MAC和Split MAC有比较详细的定义^[1][2]，Local MAC与Split MAC主要的区别在于对无线帧的处理，如表2中所示，802.11帧在AP处理还是在AC处理是两者最主要的区别。根据802.11协议定义，802.11无线帧分为无线控制帧、无线管理帧和无线数据帧。无线控制帧包括RTS、CTS、ACK、PS-POLL等，Local MAC和Split MAC架构下都在AP端进行处理；无线管理帧包括Beacon、Probe、Association、Authentication等，Local MAC架构下在AP或者AC处理，Split MAC架构下将其中实时部分放在AP端处理，非实时部分放在AC端进行处理，如表3所示；无线数据帧，Local MAC架构下在AP端进行处理即转变为802.3帧进行传输，Split MAC架构下在AC端进行处理，在AP端对802.11数据帧透传至AC端。表3列举了Local MAC和Split MAC主要功能模块的处理端，对于部分功能（例如Frag./Defrag.，Assoc./Disassoc./Reassoc.等）协议并没有明确规定处理端，因此各厂商对这部分功能的实现也是各有不同。对于表2中所描述的在Split架构下，802.11无线帧的实时功能和非实时功能的界定也是相对模糊的，各厂商均有自己的理解。况且，即使协议有明确规定功能的处理端，部分厂商还是以私有的形式对其进行处理，而这些最终都会对AP-AC的互联互通、接口开放产生影响。以下为采取Local MAC架构和Split MAC架构厂商的现状：

（1）Local MAC架构下，802.11报文在AP终结会丢失关于802.11报文头中的信息，例如Type、SubType、ToDS、FromDS、Station省电模式标识位、BSSID等，当前Local厂商通过另外的手段将这些信息送传至AC，比如通过新的控制报文或者通过802.3中的保留字段来传送，而具体通过CAPWAP哪些控制报文、报文中的哪些字段、802.3中哪些保留字段，各厂商之间都是有差别的。Local MAC架构下的AC负担比较小，而AP的功能相对强大。

（2）Split MAC架构下，802.11报文在AC终结不会有报文头丢失的问题。Split厂商认为，802.11报文头中的信息，例如Type、SubType、ToDS、FromDS、Station省电模式标识位、BSSID等，将会用来进行关联、Qos操作以及区分802.11管理报文和数据报文的优先级。Split厂商认为，在Split架构下，功能实现位置比较清晰、有标准可循，而且有利于长远演进。Split MAC架构下的AC功能相对强大，而AP对应的功能比较少。

 

功能描述		Local MAC	Split MAC
Function	Distribution Service（分发服务）	AP/AC	AC
	Integration Service（集中服务）	AP	AC
	Beacon Generation（Beacon处理）	AP	AP
	Probe Response Generation（Probe处理）	AP	AP
	Power Mgmt/Packet Buffering（节电管理/报文缓冲）	AP	AP
	Fragmentation/Defragmentation（分片、重组）	AP	AP/AC
	Assoc/Disassoc/Reassoc（关联/解关联/重关联）	AP/AC	AC
IEEE 802.11 QoS	Classifying（WMM 流分类）	AP	AC
	Scheduling （WMM 调度）	AP	AP/AC
	Queuing    （WMM 队列）	AP	AP
IEEE 802.11 RSN(WPA2)	IEEE 802.1X/EAP	AC	AC
	RSNA Key Management（密匙管理）	AC	AC
	IEEE 802.11 Encryption/Decryption（加密解密）	AP	AP/AC

 

表3 CAPWAP功能列表

 

事实上，各厂商对CAPWAP协议理解的差异造成了各厂商关于AP-AC之间接口定义的区别。比如对Local MAC架构和Split MAC架构的理解，各厂商之间就已经达不成一致，后续AP-AC接口的开发就更不可能统一。除了表3所列举的功能外，还有很多功能，例如涉及到接口加密、信道均衡的选择、参数传递等等，每家厂商对于这些功能所具体应用的算法也是不一致的，结果会导致算法参数选择上的不一样。往往这些算法是一个企业或者一家厂商知识产权的核心部分，若要对AP-AC接口进行统一，这些算法将不可避免的公开，以供大家进行探讨。

架构的选择应该考虑到整个网络后续的演进，是否对后续新增的协议或者功能具备兼容性。当前国内的厂商除了华三和傲天动联选择Split MAC架构之外，剩余厂商都采用Local MAC架构。而国外的厂商，如思科、摩托罗拉等都采用Split MAC架构，因此，选择Split MAC架构是整个WLAN网络架构的一种趋势。从移动公司的角度来讲，WLAN网络的可管理性、易维护性应当成为选择何种架构的关键因素，Split MAC架构下AC功能强大而AP功能需求相对弱小，将会更加符合我公司对WLAN网络的要求。

随着我公司WLAN网络建设规模的快速扩大、厂家数量的持续增加，为更好的运营、维护、升级WLAN网络，我公司只能在短期内先通过企标规范的形式来推动AP-AC之间接口的开放。待规范基本成熟后，再考虑提交标准化组织的可行性。后续出现新的功能需求后，需将各厂商的实现方式进行统一后纳入标准进行常规的维护。

图1 CAPWAP隧道

三． AP-AC接口的CAPWAP隧道实现方式

RFC协议^[1]规定通过建立CAPWAP隧道来规范AP-AC之间的通信。CAPWAP隧道实质上是应用于传输层和应用层之间的一种封装格式，如图1所示。协议规定CAPWAP隧道分为控制隧道和数据隧道，控制隧道传递CAPWAP控制信息，数据隧道传递CAPWAP数据信息。AP-AC之间通过CAPWAP状态机来建立隧道，CAPWAP状态机的示意图如图2所示。从统一AP-AC接口规范的角度来讲，CAPWAP隧道建立的统一是基础，在此统一的平台上，再扩展后续的功能。所以，CAPWAP隧道的建立即CAPWAP状态机的统一是整个AP-AC接口统一的前提。

从图2中看出，整个CAPWAP隧道建立的状态有：Start，Idle，Discovery，Sulking，DTLS Setup，Authorize，DTLS Connect，DTLS Teardown，Dead，Join，Configure，Image Data，Data Check，Run，Reset，其中DTLS为CAPWAP报文传输层安全协议，为应用层数据传输提供安全保障，防止Client/Sever模式的数据在传输中被窃取或伪造。

图2 CAPWAP状态机示意图

协议规定AC具有3个线程，但开发者不一定要必须使用这些线程：

（1）监听线程：AC端的监听线程会时刻监视本地的DTLS会话建立请求，通过DTLS监听命令来传达。

（2）发现线程：AC的发现线程服务于AP与AC间的发现过程。

（3）服务线程：AC端的服务线程对应每一个已建立连接AP的状态，存在于状态转移中。当AP与AC之间通信结束，服务线程便会释放当前占用的所有资源。

整个CAPWAP隧道的建立如图2中状态转移的顺序进行，AP发出Discovery Request消息给AC，AC接收到Request信息后返回Response信息给AP，AP从消息中得到AC的IP地址从而完成AC的发现。AP根据一定的规则（例如通过优先级或者负载数量）选择连入的AC，通过授权认证建立DTLS机制。完成DTLS机制后，AP与AC进入Join状态，AC下发配置给AP，AP与AC进行Image Data交互，完成版本确认。AP与AC完成Data Check之后，就会进入Run状态。而AP与AC之间涉及到的STA信息全部是通过Run状态下AP与AC的交互完成的。而剩余的状态为AP与AC之间不具备正常连接时所进入的状态，比如静默状态等等。CAPWAP状态机并不是每个状态都需要在AP或者AC上运行。

根据上述CAPWAP状态机的运行流程可以看出，CAPWAP隧道其实可以分为两种，建立DTLS机制之前和之后的隧道，即不加密CAPWAP隧道和DTLS加密CAPWAP隧道。RFC协议规定CAPWAP控制隧道如下：

（1）CAPWAP非加密控制隧道帧结构（CAPWAP非加密控制信道仅用在AP与AC之间的发现过程——Discovery Request和Discovery Response）

+-------------------------------------------+

| IP  | UDP | CAPWAP | Control| Message      |

| Hdr | Hdr | Header | Header | Element(s)  |

+-------------------------------------------+

（2）CAPWAP DTLS加密控制隧道帧结构

+------------------------------------------------------------------+

| IP  | UDP | CAPWAP    | DTLS| CAPWAP | Control| Message   | DTLS |

| Hdr | Hdr | DTLS Hdr  | Hdr | Header | Header | Element(s)| Trlr |

+------------------------------------------------------------------+

\---------- authenticated -----------/

\------------- encrypted ------------/

从帧结构上可以看出，CAPWAP两种控制隧道的主要差异在于加了DTLS控制字段。RFC协议规定CAPWAP数据隧道如下：

（1）CAPWAP非加密数据隧道帧结构，非加密CAPWAP数据报文的应用往往以wireless payload内的无线帧已做够安全加密（如WEP、802.1X、WPA等等）为前提

+-------------------------------+

| IP  | UDP | CAPWAP | Wireless|

| Hdr | Hdr | Header | Payload |

+-------------------------------+

（2）CAPWAP DTLS加密数据隧道帧结构

+--------------------------------------------------------+

| IP  | UDP | CAPWAP    | DTLS| CAPWAP | Wireless | DTLS |

| Hdr | Hdr | DTLS Hdr | Hdr | Hdr     | Payload  | Trlr |

+--------------------------------------------------------+

\------ authenticated -----/

\------- encrypted --------/

同样CAPWAP数据隧道的区别也是在于是否加入了DTLS控制字段。

使用DTLS机制会使控制隧道和数据隧道传递的报文的安全性得到提高，AC通过鉴别AP的证书可以保证接入设备的合法性，但是使用DTLS机制对整网AP部署证书时，同样会提高整网升级和维护的工作量。因此，选择DTLS加密机制需要综合考虑现网的规模大小以及具体应用的情景。RFC协议^[2]定义了CAPWAP的绑定协议，该协议对Local MAC架构下和Split MAC架构下AP与AC的功能进行了一定的划分是对RFC 5415协议^[1]功能的补充。

四．AP-AC接口开放工作思路前景

瘦AP+AC架构是WLAN组网发展的趋势，因此AP-AC之间接口的开放也只是一个时间上的问题。虽然各厂商对于AP-AC间的接口定义各异，但是他们却一致的认为AP-AC接口的开放将会逐步演变成为现实。从上面的分析，我们不难看出，按照中移动WLAN企标规范的功能要求对AP-AC通信接口进行标准化，有如下几方面的工作需要完成：

（1）AP-AC间控制隧道建立时，各过程的实现方式

（2）统一产品信息：每个厂商自己的独有的厂商号、产品号

（3）统一加密算法：基于加密通道的加密方式、加密方法

（4）统一交互流程：基于Local MAC架构和Split MAC架构下的厂商之间具体功能交互过程

（5）统一实现位置：功能的具体实现位置

（6）统一字段：Local MAC架构下各厂商如何将802.11报文中丢失的部分信息传送至AC

（7）统一报文格式：Local MAC架构下各厂商管理报文的报文格式

（8）统一交互TLV

（9）统一添加中移动WLAN企标规范定义的功能项，实现的报文及TLV格式

而整个接口标准化的进程也可以按照如下的工作思路逐步实现。

第一阶段：实现AP-AC之间基本功能的互通，依据RFC5415状态机建立起AP-AC间的CAPWAP隧道，统一状态机中各功能的交互流程、实现位置、TLV，该阶段并不涉及中移动WLAN企标规范规定的功能项，以及DTLS加密机制。整个第一阶段需要实现的主要部分包括以下几个方面：

（1）           AP–AC的相互发现和相互选择的过程

（2）           AP–AC协商加密隧道的过程

（3）           AP–AC建立连接的过程

（4）           AP–AC下载初始化配置的过程

（5）           AP–AC升级AP软件版本的过程

（6）           AP-AC实现基本功能项所需要的厂商自定义元素

第二阶段：依据中移动WLAN企标功能要求，逐步加入各个功能。明确MAC架构、每个功能的交互流程、实现位置、TLV等。包括自动信道选择、Station上下线、负载均衡等。

第三阶段：实现网管功能以及协商DTLS机密机制，后续添加新功能时需共同讨论实现流程、实现位置、TLV等，并随着现网的应用更新至企标规范。

权限： 公开   来自：labs

声明： 本文仅代表作者个人观点。其原创性及文中表达的意见、判断、数据、观点和陈述文字等内容均与中国移动研究院无关。移动Labs博客致力于为ICT领域的研究者及从业者提供技术和业务交流的网络平台，对本文中全部或部分内容的真实性、完整性不作任何保证或承诺，仅供读者参考交流。