文/ 史扬

运营商和企业大规模部署AP时，对AP升级软件、设置无线参数等管理工作将给用户带来很高的操作成本。2003年左右，瘦AP架构成为了WLAN在企业等应用发展的新趋势，即通过无线控制器（AC）来管理多个AP（称为瘦AP），AP和AC间采用某种隧道协议进行通讯，无线接入报文的处理在AP和AC间分担实现。而传统的AP在一个AP上实现了所有无线接入等功能，被称为胖AP(FAT AP)。从软件协议角度看，瘦AP架构涉及两个关键问题：
AP和AC间的隧道协议，即主要解决AC对AP的配置管理及AC和AP之间的数据转发。
对FIT架构的管理MIB标准
以下将针对第二个问题重点介绍其解决办法。

背景及问题
IETF的SNMP MIB设计一般使用ifIndex（一个整数）标识一个被管理的接口，并以ifIndex来索引接口对其做相应的配置、状态查询等操作。对于射频接口的管理，胖AP的MIB设计自然地使用这种方法。而在瘦AP架构中，网络管理员不需要直接操作瘦AP，其直接操作对象变为了AC，操作模式发生了很大变化，因此网络管理员首先要在AC上预先做好AP的配置，由AC通过隧道协议下发給AP。为了配置指定射频接口的参数，需要对射频接口进行标识。对于AP的每个射频接口，不是用ifIndex，而是通过AP索引（AP序列号或MAC）＋射频接口ID共同标识。但是，射频接口ID从0或1开始顺序地标识AP第几个射频接口，且在一个AP上唯一，这样就会出现AP1的射频接口1和AP2的射频接口1的射频接口Id 是同一值的问题。为了唯一标识特定的射频接口，必须借助AP索引来辅助唯一标识。换句话说，由于体系架构和配置流程的变化，用ifIndex来标识被管理的射频接口的方法似乎对于瘦AP不再可用。对此，各厂家普遍做法是为瘦AP单独重新定义一套MIB，使这些MIB节点从功能角度看与胖AP的是一样的。但是面对两套管理MIB，网管人员不得不对瘦AP进行相应的修改和升级。另外，IEEE 802.11WG所定义的标准MIB，因为始于1999年，那时完全是胖AP的时代，似乎也无法适应当前的瘦AP体系架构。
难道，这就是唯一的解决办法？——即重新设计一套专门针对瘦AP架构的管理MIB标准，并且使得产品开发成本、用户操作成本、管理软件升级被迫提高，并将瘦AP架构的收益打了折扣。

虚拟无线口题
为了实现胖瘦AP管理MIB的统一，降低各方面的成本，H3C提出了"虚拟无线口"的概念。通过该技术，可以从逻辑上将AC和被管理AP作为一个统一的整体，AC如同是一个机架式设备，而AP则象是一块块业务插板。当网络管理员在AC上为AP预先准备配置时，AC软件系统将为每个射频接口自动分配ifIndex，内部维护AP索引＋射频接口 ID与这个ifIndex的对应关系，并确保ifIndex的唯一性。
由于胖AP和瘦AP都统一使用ifIndex，这样两者都可以使用相同的MIB接口，已有的胖AP MIB（包括厂商的私有或IEEE的标准MIB）接口在瘦AP架构上得到了继承和重用。网络管理员（网管软件）不需要直接对AP设备进行SNMP操作。对他来说，AC变成了一个超级AP，只是在逻辑上比普通AP有更多的射频接口（数量取决于被管理的AP），这些本来物理独立的射频接口在逻辑上成为了AC一部分。网络管理员只要对AC进行直接的SNMP操作，由隧道协议最终完成对每个AP的配置下载。

IETF CAPWAP工作组
为了解决由于隧道协议不兼容而引起的A厂家的AP和B厂家的AC无法进行互通问题，IETF在2005年成立了CAPWAP工作组以标准化AP和AC间的隧道协议和MIB管理标准。
作为隧道协议的一个重要设计目标，它将承载多种无线接入技术，如802.11和802.16。所以工作组协议包括了两部分：CAPWAP协议和无线binding协议。CAPWAP协议（RFC5415，2009年4月发布）作为通用隧道协议，完成了AP发现AC等基本协议功能，和具体的无线接入技术无关。目前工作组只提供了802.11的binding协议（RFC5416，2009年4月发布），以支持802.11网络的配置管理功能。
H3C积极参加了CAPWAP的标准制定过程。由于H3C的提案能够很好地实现胖瘦AP的统一管理，H3C作为第一作者负责了MIB接口标准的设计和制定。由于CAPWAP包括了主协议RFC5415和RFC5416，相对应的，MIB接口标准也包括了两部分：RFC5833和RFC5834。
RFC5833除了包括CAPWAP协议相关的管理对象，如隧道的状态（建立或未建立），最重要的概念就是虚拟无线口。和CAPWAP协议向对应，这个虚拟无线口在物理上可以是802.11接口、可以是LTE接口等。
RFC5834针对的是RFC5416，关注的是802.11（WLAN）实现。WLAN在配置时，除了无线射频口的配置，还包括了无线逻辑口（针对BSS）的配置。为了实现胖瘦AP统一管理， RFC5834中提出了虚拟BSS口的概念，基本思路类似于虚拟无线口。
RFC5833和RFC5834所带来的收益：

1) 实现胖瘦AP的统一管理，降低网管软件的升级成本

2) 在瘦AP架构下，仍然可以兼容和支持IEEE 802.11WG制定的MIB标准，促进产品间的互通

3) 基于瘦AP架构，可以实现多种无线技术的统一管理，包括LTE、WLAN、802.16等。

结束语
通过RFC5833和RFC5834，借助CAPWAP隧道协议（RFC5415和RFC5416）可以实现胖瘦AP的统一管理，降低用户的升级和操作成本。

本文作者史扬，是H3C无线产品线的技术专家，主要关注无线安全、802.11n、CAPWAP等技术方向。

2007年9月，史扬作为第一作者，与来自Cisco等公司的专家合作提交了相关草案的第一稿；

2007年12月，史扬参加IETF70届大会并对草案工作进行了宣讲和介绍，草案工作得到了与会专家的认可；

2008年初，IETF CAPWAP WG宣布两篇草案正式成为了工作组草案；

两篇草案经过不断改进和完善，于2010年初通过了WG LastCall评审。

2010年5月，两篇草案作为RFC5833和RFC5834正式发布；