CN106790318B - 一种软件定义网络中网络功能抽象方法及其装置 - Google Patents

Abstract

本发明提供了一种软件定义网络***中网络功能抽象实现方法及其装置，其中：定义基于规则结构的网络功能抽象描述模型，基于所述网络功能抽象描述模型，控制器对定制网络功能进行解释、并生成底层网络设备所支持的配置脚本，例如：符合Openflow协议规范的流表表项，控制器将所生成的设备配置脚本通过相关的控制协议(例如：Openflow协议)下发给底层网络设备。如此，可屏蔽网络设备以及网络功能的复杂性以及多样性，只需要创建抽象的网络功能规则条目，在其中指明目标网络功能，执行的对象以及执行动作的高层描述，而不需要了解底层网络的细节。

Description

一种软件定义网络中网络功能抽象方法及其装置

技术领域

本发明涉及通信技术领域中的，尤其涉及一种软件定义网络。

背景技术

SDN(软件定义网络)是一种新兴的网络架构，具备灵活，可管理等特性，并且更适应当前网络应用升级变化频繁等特点。SDN将控制与转发分离，并且支持对网络编程。如何使能网络可编程？网络抽象被看作是一种有效的方式，原来由底层网元所承担的网络功能将会被抽象，由一系列统一形式的，可配置的动作集所替代和实现。例如，我们可以将Openflow协议看作是传统路由、转发功能的一种抽象。一系列的流表表项被下发和配置到交换机路由器上。这些流表表项可以起到原有路由协议同样的功能：识别数据包并决定如何处理该数据包。在交换机或者路由器上不再需要安装传统的路由或者转发协议。一系列Openflow流表表项取代了原有路由转发协议，并且它们可以很方便地被配置或者编程，这就是路由转发功能的抽象。

OpenFlow是一种新型网络协议，OpenFlow提出的出发点控制转发分离架构，将控制逻辑从网络设备中分离出来，交给中央控制器集中统一控制，实现网络业务的灵活部署，并且他们设计了OpenFlow协议作为控制器与交换机通讯的标准接口。近年OpenFlow已经引起了网络设备商和网络管理员的广泛关注，使用OpenFlow协议实现软件定义网络，可以把网络作为一个整体而不是许多独立分散的设备来集中进行管理，大大提升了网络可用性和网络管理效率.

网络设备维护一个或者若干个流表，并且数据流只按照这些流表进行转发。流表本身的生成、维护完全由外置的控制器来管理。流表项并非仅指普通的IP五元组，而是由一些关键字和执行动作组成的灵活规则，并且每个关键字字段都是可以通配的。在实际应用中，网络管理人员可以通过配置流表项中具体的匹配关键字来决定使用何种粒度的流转发规则。例如，如果只需要根据目的IP进行 路由，那么下发流表项时，关键字只匹配目的IP字段，其它关键字全通配，而动作中只需要一个出端口即可实现常规的IP路由转发

OpenFlow协议是描述控制器和交换机之间交互信息的南向接口标准。OpenFlow协议支持三类消息类型：Controller-to-Switch，Asynchronous和Symmetric，每一种类型都有多个子类型，控制器和交换机之间通过这三类消息进行连接建立，流表下发和信息交换，实现对网络中所有OpenFlow交换机的控制。

如前所述，Openflow流表是传统路由转发功能的抽象，除此之外，没有针对其他网络功能的抽象。

即使是Openflow对于传统路由的抽象，也存在一些缺点：网络编程者必须了解底层网络设备的细节。举例来说，当他需要针对某些数据包定制某一条路由规则时，首先他需要找出这些特定数据包的特征并找到它们的特征域；然后需要了解设备的端口号并决定从哪个端口转发；最后他需要创建完整的流表表项并通过标准的接口下发给网络设备。整个过程非常复杂，对于网络管理员来说都不轻松，更何况网络应用开发者。需要指出的是，我们这里所说的网络应用不是指用户级的应用(如视频，web，游戏等)，而是指网络层的应用(如路由，DHCP，负载均衡，防火墙，虚拟网络运营等)。

另一例子是网络租赁，网络基础设施提供商将网络资源开放给网络租户，但网络租户并不知道网络基础设施的任何细节。理想情况下，网络租户只需要提交一些关于网络功能的高层的定制需求，而需要了解网络设备的细节以及产生任何底层的配置脚本。实际上，网络租户并不需要关心网络功能是如何被实现。由此可以看出，即使是对于路由转发功能的抽象，Openflow机制仍然需要进一步的抽象以方便网络的运维。

发明内容

本发明旨在提供本发明旨在提供一种基于规则的网络功能抽象方法。为了对网络实现编程，新的网络抽象方法提供一套统一的语义声明式的抽象规则，替代传统的底层的命令式的接口，方便网络运营商或者网络开发者以一致的方式定制各种不同的网络功能。

根据本发明的一个方面，这里提供一种软件定义网络***中网络功能抽象实现方法，包括：定义基于规则结构的网络功能抽象描述模型；基于所述网络功 能抽象描述模型，控制器对定制网络功能进行解释、生成底层网络设备所支持的配置脚本；控制器将所生成的配置脚本通过相应的控制协议下发给底层网络设备。

优选地，前述配置脚本为符合Openflow协议规范的流表表项，相应的控制协议为Openflow协议。

优选地，前述网络功能抽象描述用于定义***网络层应用，描述模型包括：匹配域和动作域，分别用于表示一个特定网络功能和实现该特定网络功能方法。

优选地，前述匹配域进一步包括执行所述特定网络功能所需要的目标对象。

优选地，前述目标对象包括：源IP地址SIP、目的IP地址DIP、协议、或端口。

优选地，前述动作域为一个典型的类型域一数值域对，用于定义匹配域中特定网络功能实现方法。

优选地，前述类型域表示实现特定网络功能的处理类型，数值域表示实现相应特定网络功能的处理类型所需要的参数，其中，所述类型域包括以下类型或其组合：流类型，该类型用于那些可以通过流Flow或者包处理方式来实现的网络功能；重定向类型，该类型用于特定网络功能将会被重定向Redirect到特定的服务器所处理；服务质量类型，该类型用于代表与服务质量QoS控制相关的网络功能；记录类型，该类型用于表示与***记录Log相关的功能处理；或节点管理类型，该类型用于表示需要由简单网络管理协议SNMP协议支持实现的功能处理。

根据本发明的另外一个方面，这里提供一种软件定义网络***中的控制设备，其包括：接收装置，用于接收定制网络功能描述；解释装置，基于一个规则结构的网络功能抽象描述模型，对所述定制网络功能进行解释、并生成底层网络设备所支持的配置脚本；发送装置，将所生成的配置脚本通过控制协议下发给底层网络设备。

优选地，前述配置脚本为符合Openflow协议规范的流表表项，所述控制协议为Openflow协议。

优选地，前述网络功能抽象描述用于定义***网络层应用，描述模型包括：匹配域和动作域，分别用于表示一个特定网络功能和实现该特定网络功能方法。

优选地，前述匹配域进一步执行所述特定网络功能所需要的目标对象。

优选地，前述动作域为一个典型的类型域-数值域对，用于定义匹配域中特定网络功能实现方法。

优选地，所述类型域表示实现特定网络功能的处理类型，数值域表示实现相应特定网络功能的处理类型所需要的参数，其中，所述类型域包括以下类型或其组合：流类型，该类型用于那些可以通过流Flow或者包处理方式来实现的网络功能；重定向类型，该类型用于特定网络功能将会被重定向Redirect到特定的服务器所处理；服务质量类型，该类型用于代表与服务质量Qos控制相关的网络功能；记录类型，该类型用于表示与***记录Log相关的功能处理；节点管理类型，该类型用于表示需要由简单网络管理协议SNMP协议支持实现的功能处理。

根据本发明的另外一个方面，这里提供一种软件定义网络***，其包括前述的控制设备；以及网络设备，用于接收来自控制设备生成、下发的设备配置脚本并实现相应的特定网络功能。

根据本发明实施例所提供的网络功能抽象方法及其装置，它能够很好地屏蔽网络设备以及网络功能的复杂性以及多样性。运营商或者上层应用开发者只需要创建抽象的规则条目，在其中指明目标网络功能，执行的对象以及执行动作的高层描述，由此支持运营商或者网管很容易地定制特定的网络功能，也很好的支持了网络多租户场景。传统的网络功能可被抽象为一组统一格式，高层的规则条目，通过这些规则条目，上层网络应用开发者可以定制特定的网络而不需要了解底层网络的细节。作为上层应用开发者而言，他们可以将精力聚焦于实现应用逻辑本身，只需要通过简单的API接口提交高层的网络功能定制需求。

附图说明

通过下面提出的结合附图的详细描述，本发明的特征、性质和优点将变得更加明显，附图中相同的元件具有相同的标识，其中：

图1是本发明所提供的网络功能抽象--规则结构示意图；

图2是本发明所提供的规则结构中动作域结构示意图；

图3是本发明所提供的网络功能抽象应用--负载均衡***结构示意图；

图4是本发明所提供的网络功能抽象应用--负载均衡的抽象规则结构示意图。

图5是本发明所提供的网络功能抽象应用--负载均衡的下发到底层设备的OpenFlow流表表项。

具体实施方式

在以下优选的实施例的具体描述中，将参考构成本发明一部分的所附的附图。所附的附图通过示例的方式示出了能够实现本发明的特定的实施例。示例的实施例并不旨在穷尽根据本发明的所有实施例。需要说明的是，尽管本文中以特定顺序描述了本发明中有关方法的步骤，但是这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果，相反，本文中所描述的步骤可以改变执行顺序。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

如图1所示网络功能抽象模型--规则结构示意图，统一的、格式化的规则结构用于表示不同的***网络层应用，且该规则结构是可以很方便地被编辑或者编程。一条规则包含两个域：匹配域和动作域，一条典型的规则条目被用于描述和代表一个特定的网络功能以及实现。作为网络功能的高层抽象，规则条目并不会像Openflow流表表项那样被装载到底层的设备上。网络编程者或者虚拟网络运营商利用该规则条目定制网络功能，一般来说，该规则条目创建并维护在中央控制器上，中央控制器负责解析该规则条目并将合适的配置脚本下发到底层设备上。因此这些规则条目的执行主要由集中控制器完成，网络编程者或者虚拟网络运营商仅仅只需要定义创建规则条目本身。

不同于Openflow机制，规则中的动作域(ACTION)使用高级语义化的表述来描述该网络功能如何被实现。动作域是一个类型-数值对(Type-Value)，在数值域中并不会给出具体的配置脚本。规则定义者只需要在数值域中填入一些属性参数，通常来说该属性参数是目标网络功能的某一属性文件名称。属性文件往往是一个模板，其中给出了目标网络功能的详细表述。比如：一个预先定义的防火墙模板FW1，在这个模板中将会给出某一特定防火墙的需求以及它的防火墙策略的详细描述。这个防火墙模板的名称FW1将会被填入数值域用于指明目标的网络功能，即需要执行的防火墙。这样，对于规则定义者而言，他不需要了解具体的底层网络细节，而只需通过数值域中的参数指明需求即可。

匹配域中功能子域(FUNCTION)用于指明需要抽象的目标网络功能，即什么网络功能需要被执行或者定制。在某些情况下，匹配域还需要指明执行该网络功能所需要的目标对象，匹配域中的其他子域可用于提供目标对象的选择，其他子域可以是源IP地址(SIP)、目的IP地址(DIP)、协议或端口等。例如：某 一网络应用需要对来自某一特定源IP地址的数据流执行深度包检测(DPI)功能。那么除了功能子域(FUNCTION)需要被设置为DPI以指定该特定网络功能以外，还需要在匹配域中的源IP地址域(SIP)中指定具体的IP地址，这样就能明确表示到底需要对哪些数据包执行深度包检测。

图2是本发明所提供的规则结构中动作域结构示意图，动作域(ACTION)是一个典型的Type-Value对，用于定义匹配域中指定的网络功能实现方法，即应该如何被执行和实现。如图2所示，类型(Type)域指明了实现特定网络功能的处理类型，典型地可以包括流(Flow)类型，重定向(Redirect)类型，服务质量(QoS)类型，记录(Log/Copy)类型，节点管理(SNMP)类型等，其中：

流(Flow)类型，用于那些可以通过流或者包处理方式来实现的网络功能，这也就是意味着相关的数据流会根据Openflow流表(支持Openflow协议的设备)或者路由转发表(传统设备)来被处理。所有可以被解析为Openflow流表表项或者路由表表项的网络功能在被抽象表达的时候，其动作域(ACTION)的类型都会被设为flow型，例如路由、负载平衡、防火墙等等。相应的数值(Value)域可被设为流或者包处理的某一模板的名称。

重定向(Redirect)类型，意味着目标网络功能将会被特定的服务器所处理，因此相应的数据流将会被重定向到某一逻辑或者物理网络实体。通常来说，利用客户端-服务器模式实现的网络功能一般会被划分为重定向类型，例如DHCP(动态主机配置协议)配置，AAA(认证，授权，授权)服务等。在相应的Value域通常会给出该实现该重定向网络功能的服务器参数，例如：重定向目标服务器的IP或者域名地址，以及跟具体功能相关的属性参数，例如DHCP的地址池配置等。

服务质量(QoS)类型，代表与QoS控制相关的网络功能，并且该网络功能无法通过流控的方式来实现。同样的，Value域被用来指定相关的参数。例如，需要被实现的网络功能是队列调度，那么它的Type域就需要被设置为QoS类型，它的数值域被设置为关于队列调度的参数，例如：QS(SP)，表示采用严格优先级(Strict Priority)的队列调度方法。

记录(Log)类型，表示与***记录相关的功能处理。相应的Value域用于指示该***记录需要被完成的方式，例如：是本地拷贝或者转发到其他地方。

节点管理类型，用于表示那些需要由SNMP协议支持实现的功能处理，相应的Value域用于指示节点管理的参数。

值得说明的是，Type域的种类并不局限于上述所说的这些处理，它可以被进一步扩展以支持更多的其他网络功能，例如“Netconf”等类型用于表示需要Netconf协议支持的功能。

总的来说，网络功能抽象模型--规则结构及规则结构中动作域主要涉及：1)一系列标准的统一形式的规则项被用于表示传统的网络功能，不同于Openflow流表，这些规则项是一些***网络应用层的网络功能描述，它并不需要规则的制定者或者上层应用开发者了解底层网络的任何细节。2)解释和执行相应的规则项即可实现对应的网络功能，基于规则的网络功能抽象可以取代原来传统的网络功能实现机制，同时达到原来网络功能所需要的效果。3)具有标准格式的规则可以很容易地被编辑或者编程，方便运营商对网络功能进行编辑，不同于Openflow流表，本发明实施例规则中网络功能抽象模型每一域的域值均可以为变量，方便开发者编程实现网络功能定制。

以下申请人将给出一个具体的基于规则的网络功能抽象的实现例子，如图3所示，某些运营商需要根据网络负载情况，将上行的数据流量路由到一个BNG(宽带网关)群中的不同的BNG节点。这里我们假设接入节点AN有三个上联口(物理或者逻辑端口)分别连接BNG群中的三个不同BNG节点。当运营商需要对某些流量(访问某一热门站点)执行负载均衡操作时，那么该需求即可描述为对目标地址为某一特点IP的数据流量执行负载均衡。作为上层应用开发者，他并不了解接入节点AN到底有几个上联口，更不用说哪个上联口连接哪个BNG节点。理想情况下，上层应用开发者只需要递交高层的需求，即所需执行的网络功能名称以及执行的对象。这样，抽象的API接口如NF_Creation(LB，DstIP，LB1)，其中LB表示特定网络功能类别，例如：本实施例所涉及的负载均衡；DstIP表示该特定网络功能执行的对象，即针对目标地址为DstIP的数据流量；最后一个参数LB1表示特定网络功能类别--负载均衡功能的属性文件名，即在该属性文件中描述负载均衡功能的具体策略等内容。

抽象的API负责解析这些传入的参数并创建特定的规则条目，如图4所示网络功能抽象应用--负载均衡的规则结构示意图。

实际上，规则条目应该被登记为如下所示格式：

其中，流(Flow)参数LB1实际上是负载均衡功能的一个属性文件名。假定在LB1中指定采用轮询调度算法作为其负载均衡的实现方式，并且80％为触发点，即意味着当某一BNG节点的负载超过80％时，那么流量需要被重定向到下一BNG节点。

为了通过合适的流表表项以实现轮询算法的需求，在软件定义网络SDN控制器中的将设置一个规则驱动(Rule Driver)模块负责规则的解析和生成与底层设备交互的配置脚本产生。在本实施例中，我们假设底层设备是支持OpenFlow协议，以下给出了关于轮询算法的规则解析以及OpenFlow流表产生的实现代码。

之后，SDN控制器将所生成的OpenFlow流表通过相应的控制协议OpenFlow协议下发给底层网络设备接入节点AN。

图5示例了网络功能抽象应用--负载均衡的下发到底层设备的配置脚本，即OpenFlow流表表项，该表项可以取代原来部署在设备上的负载均衡的实现机制，并能达到和原有机制同样的负载均衡效果。图例中的OpenFlow流表可以由多个流表项组成，每个流表项就是一个转发规则，进入AN的数据包通过查询流表来获得转发的目的端口。流表项由头域、计数器和操作(Action)组成，其中：头域是个多元组，是流表项的标识，例如图例中的交换机端口(Switch Port)、MAC源地址(MAC src)、MAC目的地址(MAC dst)、以太网类型(Eth Type)、虚拟局域网标识(VLAN ID)、IP源地址(IP src)、IP目的地址(IP dst)、IP端口(IP Port)、TCP源端口(TCP sport)、TCP目的端口(TCP dport)......；计数器用来计数流表项的统计数据；操作(Action)标明了与该流表项匹配的数据包应该执行的操作，例如：将流表项中IP目的地址为DstIP的数据流量数据转发到相应的端口以发送到相应的BNG，由此可实现为对目标地址为某一特点IP的数据流量执行负载均衡。

本领域技术人员可以理解，前述实施例仅仅以网络功能抽象应用一负载均衡为例进行说明，并且假定底层网络设备接入节点AN支持OpenFlow流控制协议及操作，然而，根据所定义的网络功能不同，实现该特定网络功能方法的处理方式以及底层网络设备的支持能力也不一样，因此具体下发给底层网络设备的配置脚本以及控制协议也会存在诸多不同。例如：为抽象某一认证功能时，在动作域中往往被配置为重定向类型，即需要将相关的数据包转发到特定的认证服务器以实现相关功能；假设底层网络设备不支持OpenFlow协议，那么此时控制器则需要将规则解析为常规的转发表项，通过通用的远程控制接口下发给底层网络设备；此外，为抽象时延控制功能，在动作域中即被配置为QoS类型，相关参数指明对应的时延参数。此时控制器往往将该规则解析为转发队列配置参数，通过远程控 制接口下发给底层网络设备。

通过上述实施例描述可见：1)，仅仅通过一条符合网络抽象描述模型的格式规则条目即可代表和描述传统的特定网络功能--负载均衡，规则条目的内容以高层语言指明目标网络功能、实施对象以及相关参数。上层应用开发者或者规则制定者并不关心目标网络功能如何被实现，也不需要知道下层网络设备的细节。2)，符合网络抽象描述模型的规则条目可以在控制器中被解析为具体的设备配置脚本并配置给网络设备，例如本例中为OpenFlow流表表项，该配置脚本可能实现传统的网络功能并达到同样的效果。3)，规则的内容是可以被配置和修改的，因此规则条目是可编辑或者说可编程的，网络运营商或者上层应用开发者就可以通过定义特定的规则条目来定制特定的网络功能。

实际上，上述的三点内容就是网络功能抽象的关键特征：统一格式的高层描述，传统机制的取代以及编程使能。Openflow机制是对传统路由转发功能的抽象，但它需要网络运营者了解网络的细节，例如他需要知道某个交换机到底有多少个端口，到底从哪个端口转发某一特定流量，并组装出具体的流表表项。而本发明所提出的网络抽象机制能够很好地屏蔽网络设备以及网络功能的复杂性以及多样性。运营商或者上层应用开发者只需要创建抽象的规则条目，在其中指明目标网络功能，执行的对象以及执行动作的高层描述。由此支持运营商或者网管很容易地定制特定的网络功能，也很好的支持了网络多租户场景。作为上层应用开发者而言，他们可以将精力聚焦于实现应用逻辑本身，只需要通过简单的API接口提交高层的网络功能定制需求。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件加必需的硬件平台的方式来实现，当然也可以全部通过硬件来实施，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

以上实施例仅用以说明本发明的技术方案而非对其进行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这些修改或者等同替换亦不 能使修改后的技术方案脱离本发明技术方案的精神和范围。

Claims (12)

1.一种软件定义网络***中网络功能抽象实现方法，其特征在于：

定义基于规则结构的网络功能抽象描述模型，其中所述网络功能抽象描述模型用于定义***网络层应用，所述网络功能抽象描述模型包括：匹配域和动作域，分别用于表示一个特定网络功能和实现该特定网络功能方法；

基于所述网络功能抽象描述模型，控制器对定制网络功能进行解释、生成底层网络设备所支持的配置脚本；

控制器将所生成的配置脚本通过相应的控制协议下发给底层网络设备。

2.如权利要求1所述的方法，其特征在于所述配置脚本为符合Openflow协议规范的流表表项，相应的控制协议为Openflow协议。

3.如权利要求1所述的方法，其特征在于所述匹配域进一步包括执行所述特定网络功能所需要的目标对象。

4.如权利要求3所述的方法，其特征在于所述目标对象包括：源IP地址SIP、目的IP地址DIP、协议、或端口。

5.如权利要求1-4中任一项所述的方法，其特征在于所述动作域为一个典型的类型域-数值域对，用于定义匹配域中特定网络功能实现方法。

6.如权利要求5所述的方法，其特征在于所述类型域表示实现特定网络功能的处理类型，数值域表示实现相应特定网络功能的处理类型所需要的参数，其中，所述类型域包括以下类型或其组合：

流类型，该类型用于那些可以通过流Flow或者包处理方式来实现的网络功能；

重定向类型，该类型用于特定网络功能将会被重定向Redirect到特定的服务器所处理；

服务质量类型，该类型用于代表与服务质量Qos控制相关的网络功能；

记录类型，该类型用于表示与***记录Log相关的功能处理；

节点管理类型，该类型用于表示需要由简单网络管理协议SNMP协议支持实现的功能处理。

7.一种软件定义网络***中的控制设备，其特征在于包括：

接收装置，用于接收定制网络功能描述；

解释装置，基于一个规则结构的网络功能抽象描述模型，对所述定制网络功能进行解释、并生成底层网络设备所支持的配置脚本，其中所述网络功能抽象描述模型用于定义***网络层应用，所述网络功能抽象描述模型包括：匹配域和动作域，分别用于表示一个特定网络功能和实现该特定网络功能方法；

发送装置，将所生成的配置脚本通过控制协议下发给底层网络设备。

8.一种如权利要求7所述的控制设备，其特征在于所述配置脚本为符合Openflow协议规范的流表表项，所述控制协议为Openflow协议。

9.一种如权利要求7所述的控制设备，其特征在于所述匹配域进一步执行所述特定网络功能所需要的目标对象。

10.一种如权利要求7或9所述的控制设备，其特征在于所述动作域为一个典型的类型域-数值域对，用于定义匹配域中特定网络功能实现方法。

11.一种如权利要求10所述的控制设备，其特征在于所述类型域表示实现特定网络功能的处理类型，数值域表示实现相应特定网络功能的处理类型所需要的参数，其中，所述类型域包括以下类型或其组合：

流类型，该类型用于那些可以通过流Flow或者包处理方式来实现的网络功能；

重定向类型，该类型用于特定网络功能将会被重定向Redirect到特定的服务器所处理；

服务质量类型，该类型用于代表与服务质量Qos控制相关的网络功能；

记录类型，该类型用于表示与***记录Log相关的功能处理；

节点管理类型，该类型用于表示需要由简单网络管理协议SNMP协议支持实现的功能处理。

12.一种软件定义网络***，其特征在于包括：

如权利要求7至10任一项所述的控制设备；以及

网络设备，用于接收来自控制设备生成、下发的配置脚本并实现相应的特定网络功能。

Images