对软件定义网络数据面抽象的重新思考

中图分类号：TN915.03； TP393.03 文献标志码：A 文章编号：1009-6868 （2013） 05-0022-004

提出了一种基于标签的更加灵活的SDN交换机数据面抽象——LabelCast。LabelCast利用标签交换机制解决SDN交换机中的复杂规则匹配问题，采用Cast程序扩展机制解决交换机转发面的功能可编程问题。LabelCast不但可以简化SDN数据面规则匹配复杂性，还可以通过在数据面加载应用的处理程序支持可编程的数据面功能扩展。

软件定义网络；数据面；抽象

In this paper， we propose a flexible data plane abstraction for software-defined networks. This abstraction is called Labelcast. The complex rule-matching problem can be solved by using label switching mechanisms， and programming the functions of the switch-forwarding plane can be simplified using the Cast program extension mechanism. Labelcast decreases complex rule-matching and supports function extensibility in the data plane of SDN switches.

software-defined networks； data plane； abstraction

经过多年发展，软件定义网络（SDN）/OpenFlow的研究和标准化进入一个关键阶段。

一方面，美国计算机协会数据通信专业组（SIGCOMM）上首次出现多篇SDN的论文，标志着SDN正式受到学术界的认可。中国盛科公司推出业界第一款支持OpenFlow多级流表的芯片Bigbelt和支持OpenFlow1.3标准的交换机产品V350。同时，2013年4月OpenFlow 1.3.2标准推出，保持半年更新一个版本的速度。

另一方面，对SDN/OpenFlow的理性思考也逐渐增加，2013年5月SDN技术主要推动者加州大学伯克利分校的Scott Shinker将自己演讲的题目定为“Software-Defined Networking at the Crossroads”，认为SDN的发展正处在一个十字路口，重大转型即将出现。SDN的重要发明人Martín Casado在其论文中认为目前OpenFlow是在网络核心和网络边缘对数据平面需求的一个“An Unhappy Medium”。工业界评论中也越来越多出现了类似“OpenFlow不是网络演进的唯一路径”的标题，甚至著名的IT评论网站Network Computing的评论做出了OpenFlow在2014年必死的预测（Prediction： OpenFlow Is Dead by 2014）。设备厂商在2013年也推出了协议无关转发（POF）技术，将SDN中的OpenFlow演化到更加灵活的编程模型，而不再受预先定义协议类型或转发规则的限制。报文转发行为可由控制器上的软件通过细粒度的转发指令（包括数据偏移量和长度）定义，而转发的报文可以不再经过软件控制器的处理。基于POF，路由器的转发引擎已经不再与协议类型相关，因此支持更多的应用场景。

本文首先对OpenFlow提出的背景和发展历程进行了重新审视，重点对OpenFlow标准化中的一些技术上的重要决断进行讨论和对OpenFlow最新的发展动向进行分析，通过分析指出复杂的转发规则匹配和难以支持新型网络体系结构的部署是目前OpenFlow发展遇到的重要难题。然后对多协议标签交换（MPLS）部署的成功进行分析，通过借鉴MPLS体系结构在简化转发处理和支持多种协议方面的优点，本文提出了新的SDN网络数据面抽象——LabelCast，介绍了LabelCast的工作原理，并对实现的相关问题进行了讨论。

1 OpenFlow发展面临的

问题

1.1 OpenFlow最初需要解决的问题

Martin Casado在2008年的文献[1]中指出，硬件实现转发要有3个重要的特性：软硬件接口明确、硬件实现简单、支持灵活高效的功能实现。

文献[1]认为目前硬件实现分组转发的逻辑十分复杂，因此提出了首先由软件对报文流的第一个分组做出转发决策，然后由硬件模仿这一决策，对流内后续的分组进行转发的方案。这种转发的特点是各种网络协议实现对硬件没有限制，即硬件设计不必为支持某种特定的协议而进行专门优化。同时网络硬件实现对协议也没有限制，未来出现的各种协议也不会因为硬件平台的限制而难以部署。

OpenFlow白皮书[2]也提出了OpenFlow设计的4个原则：高性能低成本实现、支持多样化的网络实验、隔离实验流量和正常流量、支持设备制造商封闭其内部实现方法的需求。由于OpenFlow没有过于追求可编程性而忽略设备制造商封闭内部实现细节的需求，因此虽然主张开放网络设备的内部流表接口，但并没有受到设备制造商的抵制。

上述两篇论文对OpenFlow的早期发展具有重要影响。随着OpenFlow得到广泛研究，其不仅仅是在校园网上支持网络实验部署的方法，更为互联网体系结构的发展带来新的思路。

1.2 OpenFlow现在面临的问题

OpenFlow的发展目前面临很多问题，最重要一点是OpenFlow协议难以满足SDN内涵不断发展的需求。SDN近年来得到广泛研究，其技术内涵也在不断拓展。特别是软件定义互联网体系结构和软件定义Middlebox联网等新概念对SDN数据面的需求不断变化。这使得最初面向实验网络部署而设计的OpenFlow协议难以支持。例如文献[3]提出了网络体系结构与网络基础设施解耦的软件定义互联网体系结构（SDIA）的思想，指出互联网基础设施（如路由器、交换机和Middlebox等）实现只有与具体网络体系结构无关，才能在基础设施不变前提下支持多种网络体系结构的部署。

然而OpenFlow协议规范制订时并没有考虑上述问题。例如为支持灵活的规则匹配，OpenFlow即可采用类型/长度/值（TLV），也可采用偏移量/长度/值（OLV）的匹配方式。从软件编程角度TLV实现简单，从硬件设计角度OLV实现简单。

然而最终选择TLV还是OLV不仅仅决定规则匹配灵活性、实现复杂度以及与流水线处理模型的匹配能力，还代表是否将网络体系结构或协议的知识嵌入OpenFlow转发平面，是OpenFlow协议发展中的重大决策。然而从OpenFlow的Maillist中我们可以发现，由于缺少设备制造商的参与，在规范制订过程中，对选择OLV还是TLV的讨论十分简单，只有几个人参与，最后草草决定支持TLV而放弃OLV。随着2011年OpenFlow1.2标准的推出，正式宣告OpenFlow无法支持可演进的体系结构基础设施。

由于OpenFlow标准制订过程多由网络应用提供商主导，设备制造商参与相对较少，导致OpenFlow协议标准难以符合设备制造商和网络运营商的利益。主要表现在：

（1）随着新版本协议规范的推出，OpenFlow规定的处理模型越来越具体，规则匹配难度越来越大。与现有技术相比，OpenFlow并没有简化网络设备硬件的设计，只在实用性和通用性之间做了折中。例如核心MPLS交换机只要对几十比特的标签进行查表，而OpenFlow交换机却要对几百比特的规则进行匹配。

（2）OpenFlow破坏端到端的设计原则。传统互联网设计哲学认为网络中交换机和路由器的基本功能是做分组的交换和转发，是无状态的。而被认为对网络体系结构有害的Middlebox设备是有状态的，因为Middlebox在为互联网新型服务部署提供平台的同时，也在影响互联网端到端的特性。目前研究表明[4]，SDN对提高Middlebox的可管理性具有重要意义，包括实现数据流的按需重定向和负载均衡等。OpenFlow的发展使得网络路由交换设备（OpenFlow交换机）和Middlebox间的界限变得模糊，例如在OpenFlow邮件列表中使用的典型OpenFlow规则[5]如下：

捕获从端口1来的报文（可能包含Vlan Tag也可能没有），目的地址是192.168.1.1的80端口（TCP协议），将该报文的目的IP地址改写为10.0.0.1，端口号改为8080端口（TCP协议），并把其从端口2发出。

这使得研究人员担心，随着OpenFlow技术的应用，OpenFlow的分组处理方式越来越向有状态的Middlebox靠近，互联网的端到端原则可能会被进一步破坏。

（3）由于OpenFlow标准制订过分依赖网络应用提供商，没有得到设备制造商和相关芯片设计商的充分支持，因此OpenFlow设备，特别是芯片的研发缓慢。OpenFlow虽然被誉为“网络的X86指令集”，但目前网络的基础设施并不支持OpenFlow，开放网络基金会也只能成立FAWG工作组，研究如何在传统网络设备上支持多流表的OpenFlow。其基本思路是设计一个硬件抽象层（HAL），先支持OpenFlow在传统硬件上运行，直到能够支持OpenFlow的网络设备硬件出现为止。

2 SDN数据面研究

目前关于SDN数据面的研究和反思主要体现在两个方面：一是如何有效与MPLS结合，利用MPLS在简化交换规则和多协议支持方面成功的经验；另一方面是在实现上如何利用飞速发展的多核处理平台，解决OpenFlow硬件支持不利的问题。

2.1 SDN与MPLS

作为目前SDN主要的数据面抽象，OpenFlow主要面临规则匹配复杂性等问题，因此可以借鉴MPLS的设计思想。

因为MPLS最初设计主要为在IP中引入了ATM，解决的两个问题正好是目前OpenFlow发展中遇到的难题，即：（1）提高转发速度。MPLS只在网络边缘分析IP报文头，而在网络核心的转发只需简单的查找固定长度的标签表，简化了处理复杂性。（2）MPLS在无连接网络中引入连接模式的特性。通过生成标记交换面将选路和转发分开，因此支持IPv4、IPv6和IPX等多种协议。

随着专用集成电路芯片（ASIC）技术的发展，路由查找速度已经不是阻碍网络发展的“瓶颈”。这使得MPLS在提高转发速度方面不再具备明显的优势。但由于MPLS结合了IP网络三层路由和二层交换的机制，使得其能够容易地实现IP与ATM、帧中继等层网络的无缝融合，并为流量工程（TE）、虚拟专用网（VPN）、服务质量（QoS）等应用提供性能更好的解决方案。

在网络基础设施与网络体系结构分离的思想指导下，网络基础设施中的硬件应该简单，独立于特定厂商的解决方案并且支持未来新的体系结构（Future-Proof）。文献[6]指出网络体系结构设计实际包含3种接口：（1）主机-网络接口，即主机告诉网络如何处理其发出的报文，信息主要通过报文头携带，包括目的地址信息，ToS信息等。（2）操作-网络接口，即网络管理员向网络注入策略的接口。（3）报文-交换机接口，即报文告诉交换机如何对其进行交换。传统网络没有区分主机-网络接口和报文-交换机接口，也没有专门设计操作-网络接口，目前SDN实现了独立的操作-网络接口，但没有实现主机-网络接口和报文-交换机接口分离。MPLS通过网络边缘与网络核心分离，实现了主机-网络接口和报文-交换机接口的分离，所以在SDN发展中，应该借鉴网络核心的控制与网络边缘的控制解耦的思想，网络边缘支持更多的网络功能，而网络核心相对简单。

目前的OpenFlow协议处于十分尴尬的地位，在通用性上无法满足网络边缘的需求，而用在网络核心则过于复杂。

2.2 SDN与多核平台

目前网络技术发展正处在一个转型的阶段，主要特点就是由基于多核平台的软件转发取代由ASIC主导的硬件转发。多核平台在近年来发展迅速，基于多核的虚拟机平台得到广泛应用。多核平台Hypervisor实现不同虚拟机之间的数据交换和平台的IO虚拟化，可作为距端系统最近的第一跳交换机。因此多核是实现主机-网络接口交换的主要手段，也可以通过软件编程扩展支持更多的功能。

2012年Intel公司推出Cave Creek平台和DPDK，对多核平台上网络处理的直接内存存取（DMA）、缓冲区管理、队列管理等性能进行优化，使多核平台在数据面网络处理的性能大大提升。

基于上述趋势，文献[7]提出未来网络边缘功能将由软件实现，而硬件ASIC主要在网络核心进行简单的基于标签的高速转发。而实现转型的使能技术就是逐渐成熟的多核平台，主要表现在：（1）软件转发平台是稳定的可扩展的，可以支持各种新的转发操作需求；（2）多核转发平台本身的性能在不断提高；（3）软件交换已经在目前的网络中普遍存在，每个虚拟机的Hypervisor实际就是一个软件交换机。

文献[7]指出在2012年，软件交换机的端口数目已经大于硬件交换机的端口数目。因此，在SDN数据面研究时，需要充分考虑多核平台对数据面实现机制的影响。

3 新的SDN数据面抽象

基于对OpenFlow发展面临的问题、MPLS成功经验和多核平台发展趋势的分析，我们提出了一种基于标签（label）的新型SDN数据面抽象——LabelCast。LabelCast的特点是基于标签的硬件转发和基于多核平台的可编程数据平面功能扩展。

3.1 标签交换原理

受MPLS转发机制的启发，我们发现除基于OLV的规则匹配外，使用弱语义定长标签的匹配也是实现协议无关网络基础设施转发的手段。文献[1]提出的新型转发思路为：软件的转发决策可以是基于语义分析的，即需要感知协议类型，而硬件转发可以是无语义的，仅仅根据软件转发的决策进行规则匹配即可。基于该思想，LabelCast的转发硬件只根据报文携带的标签对分组进行转发。而不关心分组是属于IPv4、IPv6甚至是未来的其他网络体系结构的分组。与OpenFlow类似，转发硬件对标签表查表不命中的分组送控制器处理。控制器（及其相关软件）根据分组具体语义决定分组的转发行为，并将该分组绑定到一个标签上，与MPLS类似，相同转发等价类的分组将会绑定到一个标签，标签和转发等价类的绑定通过控制协议传递。由于LabelCast的转发平面并不需要理解报文结构和标签的含义，因此支持未来新的体系结构。

基于Label的SDN交换的主要步骤如图1所示：

步骤1：在基础设施上运行体系结构A（例如IPv6体系结构）的程序，该程序向控制器注册，注册提供的内容包括申请标签空间大小，IPv6分组的特征（如以太网帧类型域中IPv6对应的值）等。

步骤2：基础设施的控制器根据IPv6程序的要求，向其分配本地IPv6程序的可用的标签空间。IPv6程序负责该标签空间标签的管理，包括分配和回收等。

步骤3：交换机接收到第一个IPv6分组，其中标签域为空，此时交换机中标签表只有default表项，如图1（b）所示。

步骤4：由于该分组的标签域为空，交换机将该IPv6分组送控制器；控制器根据各种体系结构注册的分组特征，识别这是一个IPv6的分组，将该分组送IPv6程序处理。

步骤5：IPv6程序根据控制平面行程的转发规则（IPv6路由协议、配置的转发策略等），确定该报文的转发行为和输出接口。在确定转发规则时，既可以使用最长前缀匹配、也可以使用OLV和TLV形式的匹配。同时为该流的报文对应分配一个输入标签L1。

步骤6：应用程序通过控制器将该标签及其对应的操作写入标签表，如图1（c）所示。

步骤7：应用程序同时将流与标签L1的映射关系通知上游节点。

步骤8：该流的第一个报文根据标签表定义的动作转发到下一跳，由于输出标签为空，因此该报文输出时不携带标签。

步骤9：应用程序从下游接收到标签映射关系，即下游要求将该流与标签L2绑定。

步骤a：应用程序更改标签表，更改后如图1（c）所示。

步骤b：从上游接收到该流的第二个报文，该报文已经在头部插入L1标签。

步骤c：该报文直接查找标签表，命中，按照规定的动作处理，最后将标签替换为输出标签L2发出。

LabelCast的交换机制与MPLS的主要区别包括：LabelCast的标签交换为端到端的处理，而MPLS的标签交换只在网络核心实现；LabelCast的标签分配由SDN的应用（不同体系结构的处理软件管理）实现，而MPLS由路由器路由系统实现。当然，在标签分配方面，LabelCast可以完全借鉴MPLS的标签分配方法，但是否可以直接使用MPLS的LDP协议还有待进一步研究。

3.2 可编程数据平面功能扩展

未来网络体系结构，如信息中心网络（ICN），可能要求网络交换节点支持数据缓存等功能。因此网络基础设施的数据平面必须支持可编程的功能扩展。支持数据面可编程功能扩展的实现方法有3种。（1）FPGA，性能高但可编程能力差。（2）网络处理器，综合考虑性能和可编程能力，但处理器核支持的数据和程序空间有限，且编程困难。（3）通用多核平台，可编程性好，支持大的数据和程序空间。

综合上述分析，我们提出基于通用多核平台的可编程数据面功能扩展方案，即Cast扩展。

LabelCast和OpenFlow数据面实现方式的对比如图2所示。OpenFlow只向应用开放复杂的流表，而LabelCast将传统数据面分解为无状态的基于Label的快速交换和协议相关的Cast处理，并向应用开放转发硬件中的label表和多核平台的计算资源，应用可使用计算资源编写定义数据面处理行为的Cast程序，实现特定的数据面功能，如数据缓存，DPI、加解密等。当然，如何在数据平面上隔离不同的Cast程序，对每个Cast程序使用的计算、存储和网络资源进行有效的计量，是下一步需要研究的问题。

4 结束语

本文对SDN的数据面抽象进行了重新思考，分析了目前OpenFlow协议面临的问题，通过借鉴MPLS的成功经验和近年来多核处理平台在网络数据面处理应用中取得的进展，提出了一种新的SDN数据面抽象——LabelCast。

LabelCast利用标签交换机制可以解决复杂规则匹配问题，采用Cast程序扩展机制可以解决转发面的功能可编程问题。本文的研究工作还是初步的，很多关键技术还没有触及，我们将在下一步研究中进一步深入分析。

参考文献

[1] CASADO M， KOPONEN T， MOON D， et al. Rethinking packet forwarding hardware [C]//Proceedings of the 7th ACM Workshop on Hot Topics in Networks （HotNets08）， Oct 6-7， 2008， Calgary， Canada. New York， NY， USA：ACM， 2008：6.

[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.

[3] RAGHAVAN B， KOPONEN T， GHODSI A， et al. Software-defined Internet architecture： Decoupling architecture from infrastructure [C]//Proceedings of the 11th ACM Workshop on Hot Topics in Networks （HotNets12）， Oct 29-30， 2012， Seattle， WA， USA. New York， NY， USA： ACM， 2012：43-48.

[4] SEKAR V， EGI N， RATNASAMY S， et al. Design and implementation of a consolidated middlebox architecture [C]//Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation （NSDI12）， Apr 25-27， 2012， San Jose， CA， USA. Berkeley， CA， USA： USENIX Association， 2012：24.

[5] OpenFlow-spec：Flexible match， flexible action[EB/OL]. [2013-05-15]. https：//mailman.stanford.edu/pipermail/OpenFlow-spec/2011-April/001715.html.

[6] CASADO M， KOPONEN T， SHENKER S， et al. Fabric： A restrospective on evolving SDN [C]//Proceedings of the 1st workshop on Hot topics in software defined networks （ HotSDN12）， Aug 13， 2012， Helsinki， Finland. New York， NY， USA：ACM， 2012：85-90.

[7] SHENKER S. Software-defined networking at the crossroads [R]. Berkeley， CA， USA： University of California， Berkeley Colloquium on Computer Systems Seminar Series （EE380）， 2013-05-15.