第7章-TeamPal-软件工程项目信息化平台.doc

第7章 ? 用于软件定义WLAN的分布式MAC层架构 7.1?介绍 ?????????要充分利用未来WLAN的潜力需要一个密集部署的AP网络。传统上来说，WLAN AP?是一种低处理?能力和低智能的设备。然而，这种设计观点已经在被逐渐抛弃了，AP现在正变得越来越强大，配置了越来越多的功能。 ?????????提升AP的能力有多种原因： 首先，WLAN物理层协议的速率在过去几年里不断增长，在新的IEEE 802.11ac标准中达到了每秒数个Gbit。显然更高速的物理层需要更强大的CPU以便支持快速的帧处理，而帧处理很大一部分是由软件来实现的。 第二，新功能比如QoS和移动管理在AP上需要软件支持，一个更大的软件堆栈需要更强的CPU和内存来执行程序。比如，在流行的开源AP固件OpenWRT上当前发行的软件包的数量在过去5年增长了800%。广泛应用的Cisco 500 AP的开放系统映像大小从2007到2011年增长了超过150%。 典型情况下，一个密集的网络部??也会导致高的OPEX和CAPEX。为了减少OPEX和CAPEX，网络虚拟化和架构共享式必需的。网络虚拟化的主要原理是数个虚拟化网络通过由一个物理网络上层提供不同的网络操作。这允许更好的利用可用硬件，但是需要在虚拟网络间进行隔离。 为了实现前述提及的技术，工业界和标准委员会已经引入了新的管理协议，这种协议部分的卸除功能以便精简控制服务器。比如CAPWAP【82】允许部分去除认证服务到外部服务器中。然而，这些协议的功能被限制了，扩展是很难实现的。此外，虚拟网络的隔离是很难通过这些协议来获得的。因此迫切需要一个新的WLAN管理架构，1）能够使得网络应用程序的以一个独立于卖方的方式来部署。2）允许卸除一些时间要求不高的过程到外部服务器中。3）可量度的，能够以很高速率来处理物理层链路数据。4）支持虚拟化网络。 就像前述章节中所讨论的，SDN原则上能够满足这些需求，然而，先前章节的建议架构限制了控制SDN应用程序能够通过无线传输的次数，而且，在这个架构中MAC帧一直是在AP或者MAP中进行处理的，MAC处理的虚拟化没有被考虑。 7.1.1 相关工作 尝试建立一个基于SDN的管理架构的WLAN能够在【126】，【18】和【163】中找到，【126】和【181】提出使用OpenFlow来控制数据流，让终端用户控制数据流通过一个图形用户界面。【181】明确的提出了网络虚拟化，它建议 基于IP层和应用程序特性将网络分片。例如，一个视频流服务能够建立它自己特定的QoS设置的网络片。【181】不允许控制MAC层。Cell-SDN 【112】是最近提出来用于SDN在蜂窝网络中管理控制路径的。关键的理论是从无线电硬件中分离控制面板和在远程数据中心使用控制器， 比如执行无线电资源管理或移动管理。 ? ? 在Odin【163】文章中，物理层AP运行着提供认证服务和产生灯塔帧的软件。Odin允许使用自定义协议来通过迁移这样一种代理的状态来初始化AP之间的交付。OpenFlow利用更新网络交换机中的转发表来实现。类似于CAPWAP，在Odin中关联状态是保持在一个中心服务器和AP自己上的。在Odin，MAC帧在AP中被处理，OpenFlow不能控制MAC层。 ? ? 在【88】和【50】中，虚拟AP通过使用AP上OS的管理程序来创建。这样完全的AP虚拟化提升了灵活性，但是需要一个强大的x86架构的AP，这对于通常的WLAN部署是很难做到的。而且，【88】和【50】没有提供一个中心控制平台，而这个在上面讨论的OpenFlow却提供了。 ? ? CAPWAP【82】和它的前任LWAPP【52】是IETF标准用来拆分WLAN中MAC的处理过程。CAPWAP使用一个中心化控制器来 发现AP，配置它们同时给站点（STA）提供认证和认证服务。CAPWAP实现了一个划分的MAC层，这里一些MAC帧由AP控制器产生，其他的由AP产生。然而CAPWAP没有标准化的平台和API来部署新的网络应用程序。而且，CAPWAP需要的还是AP中较为复杂的MAC处理过程。 ? ? 7.1.2? ? 问题阐述和贡献 ? ? 由于所有相关的工作致力于一个或更多的上面描述的需求，而不是满足所有4个需求。在这个章节中，我们引入了CloudMAC，一个新的用于WLAN的管理架构。CloudMAC的关键思想是在一个WLAN AP上进行划分，物理AP只负责转发MAC帧，而虚拟AP可能放在一个数据中心或云端的虚拟机上（这也是为什么叫CloudMAC），而此虚拟AP包含了所有功能比如MAC帧产生和认证服务。虚拟和物理AP通过一个使得网络可用的OpenFlow来通信。OpenFlow转发器能够操纵控制块头部信息（包含 编码机制或传输功率?以及其他信息），按照