以博通公司专用集成电路（ASIC）芯片交换机为例，深入研究了OpenFlow表项映射至芯片三态内容寻址存储器和传统转发寄存器的机制，以达到充分利用现有ASIC资源的目的.在工业界主流交换机上进行测试的结果表明，该方案实现的OpenFlow交换机完全可行，并具备较好的实用性和扩展性.
OpenFlow is a de-facto standard programming interface between controllers and switches. How to enable the existing switches to support OpenFlow without losing their original forwarding capability is a challenge in the migration from traditional network to software defined network (SDN). Take Broadcom Trident series application specific integrated circuit (ASIC) switch as an example, an algorithm to map OpenFlow forwarding table entries into ASIC's ternary content addressable memory (TCAM) as well as traditional L2/L3 tables to augment the OpenFlow table's capability, was proposed. The feasibility and scalability of our solution was demonstrated with design, implementation and evaluation in physical switch.
软件定义网络(SDN，software defined network) 的核心思想是将控制平面的功能从交换机中分离出来，由强大的控制器统一实现[1]. OpenFlow起源于斯坦福大学的Clean Slate计划[2]，其已成为SDN中控制器和交换机通信的标准语言，以下讨论皆以OpenFlow 1.3.1版本为基础[3].由于目前主流交换机大多通过专用集成电路(ASIC，application specific integrated circuit) 来转发数据报文，所以如何使得基于ASIC芯片的交换机支持OpenFlow协议成了SDN部署中的关键一环.
笔者在研究现有交换机硬件架构的基础上，给出了能充分复用ASIC转发资源的OpenFlow流表映射算法.由于Broadcom ASIC芯片在数据中心交换机市场占据了绝对份额，笔者以Broadcom生产的Trident芯片为例来探讨OpenFlow交换机设计和实现.
1 OpenFlow交换机的演进策略目前数据中心几乎所有的交换机都依赖ASIC芯片作转发. 图 1描述了ASIC的转发过程，数据报文进入交换机后，先后经历报文解析、隧道终结、VLAN过滤处理、二层和三层逻辑处理、入端过滤(IFP，ingress filter processor)、二层和三层逻辑再处理、报文修改和压入出端VLAN、出端过滤(EFP，egress filter processor) 等处理单元，最后到达出口.
|
图 1 Broadcom Trident芯片报文处理流程 |
在ASIC中，转发流水线由多个处理单元组成，在每个单元中又包含若干寄存器用来储存和触发条件相关联的匹配表项，如图 1中的IFP和EFP，其硬件由三态内容寻址存储器(TCAM，ternary content addressable memory) 组成，主要用于快速查找ACL、路由等表项[4]. TCAM很容易实现表项的快速查找，其关联的同步动态随机存储器(SDRAM，synchronous dynamic random access memory) 用来执行相应的动作.因为TCAM可支持OSI模型中2~7层任意报文特征的匹配，交换机实现OpenFlow的最直接的方法就是将OpenFlow表项下发至ASIC芯片中IFP/EFP所对应的TCAM模块.然而，一个ASIC芯片所集成的TCAM容量非常有限，在Trident系列芯片中TCAM容量只有4 K，相比较传统的二层FDB (128 K) 和三层路由表(16 K)，处理能力非常有限.
为了解决现有ASIC芯片中TCAM容量有限的问题，目前工业界有2种方案[5]：第一，扩大TCAM容量，但TCAM面积大、发热量高、耗电量高等固有的缺点在短时间内很难解决[6]；第二，复用交换机流水线中的其他处理模块，该方案除了充分利用现有的TCAM模块之外，也利用图 1所示转发流水线中的二层、三层处理模块. OpenFlow交换机在接收到控制器创建流表的命令后，可根据表项的特征决定将流表写入ASIC对应的模块.该方案的最大优点就是ASIC制造商和交换机厂商不需要任何硬件的投入和改造，只需要在交换机侧实现OpenFlow接口并将OpenFlow流表映射至ASIC芯片不同模块.
笔者基于方案2的分析，提出最大化复用ASIC芯片处理单元的OpenFlow交换机流表映射算法.其核心思想为：对所有要求写入的流表进行类型甄别，如果流表属于ASIC芯片转发流水线支持的传统表项，则将其写入相应的寄存器；如果不属于任何一个传统表项，则写入原来用于支持ACL的TCAM当中.这样实现了传统表项的最大化利用，使得ASIC所支持的流表数目大大超过了TCAM的限制.
2 算法设计与实现 2.1 架构设计在复用现有交换机ASIC芯片传统转发单元和TCAM模块的基础上，给出面向ASIC芯片的OpenFlow交换机的设计架构，如图 2所示.
|
图 2 基于ASIC芯片的OpenFlow交换机架构 |
现有的交换机往往采用ASIC+CPU双芯片模式，其中ASIC负责报文转发，CPU负责交换路由协议的计算和对交换机资源的管理，所以操作系统所管理的硬件资源主要包括CPU和ASIC两个部分.算法最大的改动在于应用层，主要增加了4个模块：流表管理模块、控制器连接管理模块、数据传输模块和硬件适配层.流表管理模块是整个OpenFlow交换机设计架构的核心，主要负责管理OpenFlow流表项的相关部署和操作，例如添加、删除、更新等；控制器连接管理模块将交换机资源进行分割，并创建不同的实例去管理这些资源，每个实例维护一个与控制器之间的接口和链路；数据传输模块主要负责对消息进行封装，封装成OpenFlow协议并通过标准的TCP链接和控制器进行通信；硬件适配层的主要功能是将流表管理模块的指令翻译成与ASIC芯片相关的操作，并将其写入ASIC寄存器或TCAM.
在该设计中，同一个交换机可支持多个OpenFlow实例，每个实例管理不同的端口，端口之间实现流量的隔离，每个实例可连接不同的控制器.从控制器角度来说，它看到的拓扑即为多个交换机，并不能区分出这些交换机是否由一个交换机虚拟而成.这样的优势是让数据中心在部署时具备更小颗粒度和更大的灵活度，也可以节约成本.
当流表管理模块收到和流表相关的处理消息时，先根据表 1确定该表项的类型，然后转发给特定表项的处理函数，将此表项写到ASIC对应的寄存器；如果不属于任何一个表项，则当做通用表项来处理，这样的表项不能复用传统协议的硬件寄存器，只能写入ASIC中的TCAM模块.
|
表 1 OpenFlow表项类型及其特征 |
以下以多协议标签(MPLS，multi-protocol label switching) 流表为例，详细分析如何利用ASIC流水线中的寄存器实现OpenFlow MPLS流表的映射与处理.
Broadcom芯片中MPLS入标签的操作流程如图 3所示.当IP报文进入流水线时，查询通用的路由表，在出接口根据寄存器中的预先设置在报文相应位置压入MPLS标签，并进行MAC地址的替换.
|
图 3 Broadcom Trident MPLS Push处理流程 |
将图 3所示的流水线转换为对应的编程接口，设计了下发OpenFlow MPLS Push流表至ASIC的操作流程，如图 4所示.首先将入端VLAN和虚拟路由转发表(VRF，virtual route forwarding) 绑定，再创建出端VLAN，并分别和入端口及出端口绑定；然后将入端VLAN映射至VRF，确保带有不同VLAN的报文进入不同的VRF路由表处理；最后在VRF中写入具体的路由条目，并关联至存储相关动作寄存器的三层出端口即可.在此，所有流表动作皆由三层接口所指向的寄存器来完成. MPLS Push的流表被写入到传统的三层处理流水线中，而非ACL所对应的IFP模块.由此可以看出，OpenFlow交换机和传统交换机在与ASIC交互的操作基本相同，两者的关键区别在于路由表是由控制器生成还是由路由协议计算生成.
|
图 4 OpenFlow MPLS Push流表操作流程 |
由图 1可以看出，交换机ASIC流水线是顺序处理，所有的报文在经过三层处理流水线之后都会进入IFP，即TCAM模块.当前的问题是经过三层处理后的MPLS报文可能会被TCAM模块中的OpenFlow流表项误匹配，报文被覆盖或是改写，解决方法是在TCAM模块创建2条表项，第1条为匹配MPLS标签终止为条件，即匹配对应于已经执行MPLS Pop的报文；第2条为L3目标路由命中为条件，即匹配对应于MPLS Push命中三层路由表的报文.这2个表项都动作为空且优先级最高，确保了MPLS Pop和MPLS Push报文能命中IFP但不执行任何动作，使得MPLS报文绕过了IFP模块.
以上设计展示了OpenFlow MPLS相关的表项与ASIC的映射的全过程，其使用了非TCAM模块来存储OpenFlow MPLS流表；同样的策略也可应用于满足FDB及L3单播规则的OpenFlow流表，达到最大化复用传统路由转发流水线来支持OpenFlow的目的，极大地扩展了基于ASIC的交换机对OpenFlow协议支持的能力.
3 扩展性和性能分析OpenFlow交换机最重要的指标就是扩展性和性能.扩展性是指交换机所支持的流表类型和数目，性能是指交换机响应控制器的速度和报文转发速度，下面分别从这2个层面进行分析.
3.1 扩展性OpenFlow不同类型的表项容量受限制于所涉及的ASIC寄存器，如果某类表项涉及多个寄存器模块，则最终的表项条目数由关键模块决定. 表 2给出了OpenFlow不同表项扩展性的汇总.
|
|
表 2 OpenFlow不同表项扩展性汇总 |
以MPLS Push为例，该流表对IP报文压入新的MPLS标签，所以存储标签的关键寄存器IP_TUNNEL_MPLS决定了该表项的实际大小，也就是2 K.此外，IP报文必须命中MY_STATION_TCAM才能进入三层处理，所以同时要求IP报文的(VLAN+DMAC) 组合不能超过512个.同理，所有MPLS Push需要替换的DMAC数目由MAC_DA_PROFILE决定，也不能超过512个.这些条件实际上限制了数据中心网络VLAN大小、IP域主机容量和MPLS域主机的容量.对于MPLS Pop，需将每个MPLS_ENTRY条目对应至不同VRF，所以实际容量为1 K.其他任意匹配使用ASIC中的IFP TCAM模块，其容量为2 K，远远小于传统的二层交换表(128 K) 和三层路由表(16 K)，从而可以看出，充分利用ASIC中固有流水线相关寄存器能极大地扩充OpenFlow交换机所支持流表的数目.
从表 2同样可以看出，不仅同一类表项的扩展性受到所涉及的ASIC模块的限制，不同类型的表项之间也有影响.例如，MPLS Push和Pop、L3单播都使用L3_DEFIP寄存器来实现路由匹配，所以各种流表项实际可使用大小互相制约.一个极端的例子就是L3单播耗尽了全部L3_DEFIP存储空间，那么所有三层和MPLS相关的操作均无法继续进行.当然在这种情况下，控制器需要考虑各种流表项的最大空间，并且尽量对这些表项进行合理分配.
3.2 性能分析在交换机层面，性能分析可以分为2个层次，即报文转发性能和交换机对控制器指令的响应时间.报文转发由ASIC负责完成，这部分处理与上层协议类型无关，各厂家ASIC芯片对报文处理都能达到线速，这也与实际测试结果完全一致.在满配MPLS Push流表的交换机上，10 G SPF+端口满速率发送和接收没有出现丢包的情况.
表 3示出了测试所用的交换机配置.交换机采用典型的CPU+ASIC设计，由于条件限制，实验中只测试了10 G端口.
|
|
表 3 OpenFlow交换机测试规格汇总 |
从图 2所示OpenFlow交换机架构中可以看出，在交换机中，数据传输依赖于ASIC芯片，而OpenFlow协议和其他传统的交换路由协议一样运行于CPU之上，交换机对控制器指令的响应时间取决于ⅰ) CPU性能、ⅱ) 操作系统对OpenFlow进程的调度、ⅲ) 交换机接收、处理控制器消息的能力和ⅳ) 流表下发至ASIC的速度.前两者是系统设计的共性问题，后两者是OpenFlow协议所引入的新问题，以下主要对后两者进行分析.
交换机接收和处理控制器消息的能力取决于交换机CPU队列的大小.对于Trident系列来说，CPU队列长度为300.交换机接收控制器报文的速度不超过每秒300个，该报文包括控制器用于下发指令和未知报文所产生的Packet-out消息.在网络收敛之后，这样的处理能力完全满足一般网络运行的需求，因为此时无论是控制器对流表的修改还是因未知报文而产生的Packet-out消息都比较少.但在交换机重新启动并处于Proactive模式时，由于控制器在短时间内可能有大量流表项需要下发至交换机，此时CPU队列的大小就可能成为瓶颈，延迟网络收敛时间.
交换机对ASIC流表的下发速度实际上是硬件寄存器的读写速度.实际测试结果如图 5所示，1 000条MPLS Push报文在0.79 s内可写入至ASIC，1 000条MPLS Pop报文也在1 s内操作完成；至于写入TCAM的ACL类型的表项，其条目的优先级由在TCAM中的相对位置决定，所以写入时间和写入条目的优先级相关. TCAM表项中靠前的条目优先匹配，对应的优先级最高.如果所有条目以优先级递增方式写入，则在写入新条目之前，必须将之前写入的所有条目往TCAM高地址移动，这样所耗费的时间将会大大增加.实际测试中，如果以优先级递减方式写入ACL类型的流表，则每1 000条ACL类型流表项操作时间在1 s之内；如果所有流表按优先级递增方式写入，则每1 000条ACL类型的操作时间则锐增至50 s.由此可以看出，如果设计TCAM为主的面向OpenFlow的交换机，下发流表至ASIC的速度必须针对优先级做出优化，能做到操作时间随着表项数目的递增线性地增加.而传统的FDB和其他三层表项，由于采用HASH寻址写入且无法在同一种类型的流表之间再区分优先级，所以并不存在这种因为优先级的变化而写入时间大幅抖动的情况.
|
图 5 每千条不同类型OpenFlow流表写入速度 |
由此可见，这种充分复用交换机转发流水线的策略可使现有交换机在不损失转发能力的情况下支持OpenFlow协议，从而加快了软件定义网络在数据中心的部署.
4 结束语以目前主流的Broadcom Trident系列ASIC芯片为基础，分析和研究了OpenFlow交换机的若干实现细节.除了利用TCAM模块来实现任意匹配的OpenFlow报文之外，也分析了如何充分利用传统二层和三层相关的寄存器来拓展OpenFlow的条目；相应的实验表明，通过复用现有ASIC资源的OpenFlow交换机能在功能和性能上满足近阶段数据中心软件定义网络的部署需求.
| [1] |
徐雷, 张云勇, 吴俊, 等. 云计算环境下的网络技术研究[J]. 通信学报, 2012, 33(1): 16–221.
Xu Lei, Zhang Yunyong, Wu Jun, et al. Network technology research under cloud computing environment[J]. Journal on Communications, 2012, 33(1): 16–221. |
| [2] | Mckeown N, Anderson T, Balakrishnan H, et al. OpenFlow:enabling innovation in campus networks[J]. ACM SIGCOMM Computer Communication Review, 2008, 38(2): 69–74. doi: 10.1145/1355734 |
| [3] | Open Networking Foundation. OpenFlow switch specification 1. 3. 1[EB/OL].[2012-09-06]. https://www.opennetworking.org/images/stories/downloads/specification/openflow-spec-v1.3.1.pdf. |
| [4] |
刘中金, 李勇, 苏厉, 等. TCAM存储高效的OpenFlow多级流表映射机制[J]. 清华大学学报:自然科学版, 2014, 54(4): 437–442.
Liu Zhongjin, Li Yong, Su Li, et al. TCAM-efficient flow table mapping scheme for OpenFlow multiple-table pipelines[J]. Journal of Tsinghua University:Science and Technology, 2014, 54(4): 437–442. |
| [5] |
周烨, 李勇, 王芳, 等. 基于OpenFlow的网络实验平台技术[J]. 清华大学学报:自然科学版, 2012, 52(11): 1540–1544.
Zhou Ye, Li Yong, Wang Fang, et al. OpenFlow network experiment platform[J]. Journal of Tsinghua University:Science and Technology, 2012, 52(11): 1540–1544. |
| [6] | Sezer S, Scott-Hayward S, Chouhan P K, et al. Are we ready for SDN? Implementation challenges for software-defined networks[J]. IEEE Communications Magazine, 2013, 51(7): 36–43. doi: 10.1109/MCOM.2013.6553676 |