一种私有云SDN引流实现方法与流程

文档序号:16198663发布日期:2018-12-08 06:23阅读:1588来源:国知局
一种私有云SDN引流实现方法与流程

本发明涉及网络通信技术领域,具体的说,是一种私有云sdn引流实现方法。

背景技术

传统的网络转发模型主要是交换机完成的二层转发和路由器完成的三层转发。二层转发的优势是转发的规则比较简单,二层头地址mac不会因为主机位置的变化发生改变,因此基于自学习的交换机基本不用配置,管理非常方便。交换机易于用硬件芯片实现,从而获得非常高的转发性能。但二层转发模型也有很明显的弊端,比如mac地址不能聚合,导致主机增多时扩展性很弱,不能配置复杂的用户策略,并且二层网络中大量的广播报文也导致难以组成大规模网络。

三层转发模型根据报文中的ip地址进行转发。ip地址可以聚合,从而组成大规模网络,解决二层交换网络的扩展性问题。但是三层转发的配置比较复杂,而且ip地址通常也标识了主机在网络拓扑中的位置,导致主机位置迁移时难以实现自动化重配置。

在私有云网络中,目前厂商提供的网络解决方案大部分还是基于传统的二层或者三层网络模型,导致用户的网络管理配置比较复杂,难以实现灵活的用户需求。sdn是近期出现的新型的网络模型,目前主要应用在大型数据中心,完成一些网络自动化工作。本发明是sdn组网模型在私有云网络中的新应用,专门解决私有云网络中的引流问题,保证引流策略灵活性的前提下,使得用户的配置依然相对简单和高度自动化。原理是通过用户自定义规则匹配数据流,修改数据包mac地址并且转发到相应的接口。

现有技术采用策略路由引流,在网络中引入一个或者多个编排路由器,以数据报文的“源ip、端口”等转发依据进行转发,而不只是基于传统路由的目的ip地址进行转发,但需要在路由器上人工配置大量策略路由规则。

另外还有opendaylightsfc功能,opendaylight是一个开源控制器项目,其提供的sfc引流功能的应用场景是大型的数据中心,方案复杂,在网络规模较小时性能损失较大,不适合小型化的私有云场景。



技术实现要素:

本发明的目的在于提供一种私有云sdn引流实现方法,首先启动sdn控制器和ovs并且构建vnf,在sdn控制器服务程序中拓扑发现和初始化,并感知vnf的网络接口状态和mac地址,配合用户侧配置的路由地址计算和下发接入规则和引流规则,实现私有云处理用户数据收发和自动引流数据。

本发明通过下述技术方案实现:一种私有云sdn引流实现方法,基于依次连接的sdn控制器、bridge、物理主机的私有云系统实现,所述物理主机的数量有多个且每个物理主机包括一个ovs以及与ovs连接的多个vnf,每个所述ovs分别与bridge连接,具体包括以下步骤:

步骤f1:启动与bridge连接的sdn控制器和ovs;

步骤f2:构建和启动vnf;

步骤f3:在sdn控制器服务程序中拓扑发现和初始化,并感知vnf的网络接口状态和mac地址;

步骤f4:用户侧路由配置;

步骤f5:计算和下发接入规则;

步骤f6:计算和下发引流规则;

步骤f7:私有云完成用户数据报文收发。

进一步地,为了更好的实现本发明,所述步骤f1具体包括以下步骤:

步骤f11:启动bridge和每个ovs;

步骤f12:启动sdn控制器,实现sdn控制器与每个所述物理主机的ovs通过bridge互连。

进一步地,为了更好的实现本发明,所述步骤f2具体包括以下步骤:

步骤f21:启动与所述ovs连接的多个vnf;

步骤f22:根据私有云平台的统一规划设置vnf的网卡mac地址。

进一步地,为了更好的实现本发明,所述步骤f3具体包括以下步骤:

步骤f31:依据ovs接口的mac地址与vnf接口的mac地址的强相关性,sdn控制器扫描每个所述ovs的接口,并挑选出linkup接口;

步骤f32:sdn控制器检查并记录所述linkup接口上的mac地址;

步骤f33:sdn控制器计算得出与ovs相连的每个所述vnf接口的mac地址,从而形成网络拓扑图用于进行引流规则计算;所述网络拓扑图是具有根节点的树结构,所述树结构中以所述bridge为主干,所述ovs为bridge的枝叶节点,所述vnf为ovs的枝叶节点。

进一步地,为了更好的实现本发明,所述步骤f4具体包括以下步骤:

步骤f41:sdn控制器感知与bridge相连的router接口的mac地址和ip地址;

步骤f42:用户进行路由配置,帮助私有云网络计算接入规则。

进一步地,为了更好的实现本发明,所述步骤f5具体包括以下步骤:

步骤f51:sdn控制器依据openflow协议向所有的所述ovs下发一条流表规则a,所述流表规则a的内容是将收到的邻居学习请求报文上送到sdn控制器;

步骤f52:ovs收到router或者vnf发来的邻居学习请求报文后,将邻居学习请求报文上送到sdn控制器;

步骤f53:sdn控制器收到的邻居学习请求报文后,结合收到邻居学习请求报文的ovs的mac地址,构造邻居学习应答报文;邻居学习应答报文中封装的mac地址为收到邻居学习请求报文的ovs的mac地址;如果有多个ovs收到了同一个邻居学习请求报文,则sdn控制器根据负载均衡原则选择其中一个ovs的mac地址进行邻居学习应答报文封装;

步骤f54:依据openflow协议,sdn控制器向步骤f52中收到邻居学习请求报文的所述ovs下发一条流表规则b,所述流表规则b的内容是将sdn控制器下发的邻居学习应答报文转发给收到邻居学习请求报文的ovs;

步骤f55:sdn控制器依据openflow协议将步骤f53中构造的邻居学习应答报文发给步骤f52中收到邻居学习请求报文的ovs;

步骤f56:ovs将sdn控制器下发的邻居学习应答报文转发给发起请求的router或者vnf;

步骤f57:收到sdn控制器构造的邻居学习应答报文的router或者vnf学习到步骤f53中收到邻居学习请求报文的所述ovs接口的mac地址。

进一步地,为了更好的实现本发明,所述步骤f6具体包括以下步骤:

步骤f61:计算引流规则时,sdn控制器输入用户配置的引流规则d和步骤f3中维护的网络拓扑图,用户数据报文通过router进入私有云;

步骤f62:sdn控制器解析用户配置的引流规则d,得到要匹配的字段和用户数据报文要经过的设备路径;

步骤f63:sdn控制器为路径上的每个ovs计算流表规则c,每个所述ovs在设备路径中出现一次对应生成一条流表规则cn;所述流表规则cn包括报文匹配内容、路径上下一个设备接口的mac地址以及mac地址的改写规则;改写mac地址的原因是ovs要去适应与所述ovs连接的vnf和bridge的收发包原则;

步骤f64:sdn控制器根据openflow协议将流表规则cn下发给路径上对应的ovs,指引用户数据报文的转发和改写;

步骤f65:此时router已学习到步骤f52中收到邻居学习请求报文的所述ovs的mac地址,router将用户数据报文转发给所述ovs;

步骤f66:收到router发来的用户数据报文的ovs根据步骤f64中对应下发的流表规则cn进行用户数据报文的匹配、改写以及转发;

步骤f67:当用户改变引流策略时,sdn控制器自动重新计算和下发所有的引流规则;当某个vnf节点发生迁移时,网络拓扑图会发生动态变化,sdn控制器自动重新计算所有的引流规则并下发。

进一步地,为了更好的实现本发明,所述步骤f7具体包括以下步骤:私有云完成用户数据报文的匹配、改写以及转发后,将用户数据报文返回给router。

工作原理:

1.bridge连接多台物理主机,每台所述物理主机一一对应部署一个ovs,每个所述ovs分别与bridge连接,启动bridge和每个ovs;sdn控制器与bridge连接,启动sdn控制器,实现sdn控制器与每个所述物理主机的ovs通过bridge互连。

2.每个所述ovs连接多个vnf,启动vnf;根据私有云平台的统一规划设置vnf的网卡mac地址。

3.所述ovs和所述vnf有多个接口,依据ovs接口的mac地址与vnf接口的mac地址的强相关性,sdn控制器扫描每个所述ovs的接口,并挑选出linkup接口;sdn控制器检查并记录所述linkup接口上的mac地址;sdn控制器计算得出与ovs相连的每个所述vnf接口的mac地址,从而形成网络拓扑图用于进行引流规则计算。

4.sdn控制器感知与bridge相连的router接口的mac地址和ip地址;用户进行路由配置,帮助私有云网络计算接入规则。

5.sdn控制器向所有的所述ovs下发流表规则a,ovs收到router或者vnf发来的邻居学习请求报文后,将邻居学习请求报文上送到sdn控制器,sdn控制器构造邻居学习应答报文并将邻居学习应答报文返回给ovs和router,router学习到ovs的mac地址。

6.sdn控制器根据用户输入的流表规则d和网络拓扑图得到要匹配的字段和用户数据报文要经过的设备路径,sdn控制器为路径上的每个ovs计算对应的流表规则cn并下发给对应的ovs,ovs依据下发的流表规则cn进行用户数据报文的匹配、改写以及转发。

7.最后将用户数据报文返回给router。

本发明与现有技术相比,具有以下优点及有益效果:

私有云网络中的vnf实例之间需要协调工作,按照用户要求,本发明组成灵活的服务链,实现用户流量自动化地按照自定义规则经过多个nfv节点。

附图说明

图1为本发明工作流程图;

图2为数据流拓扑示意图。

具体实施方式

下面结合实施例对本发明作进一步地详细说明,但本发明的实施方式不限于此。

实施例1:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,一种私有云sdn引流实现方法,基于依次连接的sdn控制器、bridge、物理主机的私有云系统实现,所述物理主机的数量有多个且每个物理主机包括一个ovs以及与ovs连接的多个vnf,每个所述ovs分别与bridge连接,具体包括以下步骤:

步骤f1:启动与bridge连接的sdn控制器和ovs;

步骤f2:构建和启动vnf;

步骤f3:在sdn控制器服务程序中拓扑发现和初始化,并感知vnf的网络接口状态和mac地址;

步骤f4:用户侧路由配置;

步骤f5:计算和下发接入规则;

步骤f6:计算和下发引流规则;

步骤f7:私有云完成用户数据报文收发。

需要说明的是,通过上述改进,sdn是一种软件定义网络模型,所述sdn控制器为图2中的controller,是sdn网络中的集中控制器,controller可以是opendaylight、ryu等sdn控制器,所述opendaylight是一个开源控制器项目,在controller框架之上运行本方案的逻辑代码。所述ovs是openvswitch,是一种主流的支持sdn网络的软件交换机。controller与bridge连接,所述ovs有多个且分别与bridge连接。每个所述ovs连接有多个vnf。

本发明首先启动各个组件,包括bridge、sdn控制器、ovs以及vnf,sdn控制器根据bridge、ovs以及vnf的连接关系初始化发现网络拓扑图,sdn控制器感知与bridge相连的router接口的mac地址和ip地址。本发明的重点在于sdn控制器对接入规则和引流规则的计算和下发,私有云完成用户数据报文的匹配、改写和转发后,将用户数据报文返回给用户端,完成用户数据报文的收发。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例2:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f1具体包括以下步骤:

步骤f11:启动bridge和每个ovs;

步骤f12:启动sdn控制器,实现sdn控制器与每个所述物理主机的ovs通过bridge互连。

需要说明的是,通过上述改进,所述物理主机是图2中的chasis,所述chasis有多台,部署在chasis上的ovs均与bridge连接。每台chasis中的ovs连接多个vnf,所述vnf是虚拟网络功能实例,vnf功能多样化,可以是计算节点、web服务器,也可以是虚拟防火墙。

步骤f1将需要用到的主要组件启动起来,所述sdn控制器是图2中的controller,可以是opendaylight,ryu等。

每台所述物理主机都一一对应部署一个所述ovs,ovs即openvswitch的缩写,openvswitch是通过软件实现的sdn虚拟交换机,主要实现openflow定义的流表规则的转发,即与bridge连接进行用户数据报文交换。ovs与controller通过南向接口进行通信,来实现控制平面的网络通信。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例3:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f2具体包括以下步骤:

步骤f21:每个所述ovs连接多个vnf,启动vnf;

步骤f22:根据私有云平台的统一规划设置vnf的网卡mac地址。

需要说明的是,通过上述改进,vnf指的是具体的虚拟网络功能,提供某种网络服务,是软件,利用nfvi提供的基础设施部署在虚拟机、容器或者bare-metal物理机中。nfvi是私有云中一种通用的虚拟化层。

步骤f2的主要工作是在私有云平台上启动用户需要的vnf虚拟网络功能实例,vnf功能非常多样化,可以是计算节点、web服务器,也可以是虚拟防火墙,虚拟web防火墙等。在配置vnf的网卡mac地址时需要根据私有云平台统一规划,不能随意配置。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例4:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f3具体包括以下步骤:

步骤f31:依据ovs接口的mac地址与vnf接口的mac地址的强相关性,sdn控制器扫描每个所述ovs的接口,并挑选出linkup接口;

步骤f32:sdn控制器检查并记录所述linkup接口上的mac地址;

步骤f33:sdn控制器计算得出与ovs相连的每个所述vnf接口的mac地址,从而形成网络拓扑图用于进行引流规则计算;所述网络拓扑图是具有根节点的树结构,所述树结构中以所述bridge为主干,所述ovs为bridge的枝叶节点,所述vnf为ovs的枝叶节点。

需要说明的是,通过上述改进,本实施例的步骤主要在sdn控制器中进行,sdn控制器感知vnf的网络接口状态和mac地址,生成和维护网络拓扑图,用于进行引流规则的计算。

依据ovs接口的mac地址与vnf接口的mac地址的强相关性,sdn控制器扫描每个所述ovs的接口,并挑选出linkup接口,sdn控制器起到了检查并记录所述linkup接口上的mac地址的作用。

依据组件的mac地址的强相关性,计算得出每个vnf的linkup接口的mac地址,从而形成完整的网络拓扑图用于进行引流规则的计算。所述网络拓扑图是具有根节点的树结构,所述树结构中以所述bridge为主干,所述ovs为bridge的枝叶节点,所述vnf为ovs的枝叶节点。

形成拓扑图后,通过lldp协议动态维护拓扑状态,当vnf发生开关机或者迁移时,可以动态更新拓扑,无需人工干预。所述lldp协议是链路层协议,网络设备的种类日益繁多且各自的配置错综复杂,为了使不同厂商的设备能够在网络中相互发现并交互各自的系统及配置信息,需要有一个标准的信息交流平台。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例5:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f4具体包括以下步骤:

步骤f41:sdn控制器感知与bridge相连的router接口的mac地址和ip地址;

步骤f42:用户进行路由配置,帮助私有云网络计算接入规则。

需要说明的是,通过上述改进,bridge与router连接,bridge是支持传统二层转发的交换机,router是支持传统网络三层转发的路由器。如图2所示,所述私有云包括bridge、chasis以及sdn控制器,通过bridge与办公网和router连接构成私有云sdn网络的引流系统。

用户侧配置的路由器是router,所述router与私有云网络中的接入规则计算紧密相关,用户侧的路由器通常是基于策略路由将数据送往私有云网络,其对引流方案有影响的配置主要是其接口地址,所述接口地址包括mac地址和ip地址,sdn控制器需要感知与bridge相连的router接口地址,如图2所示,user的ip地址为192.168.33.1,server的ip地址为192.168.34.1,user与server的用户数据报文通过router上的策略路由发送到bridge,私有云处理完后,回送给router。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例6:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f5具体包括以下步骤:

步骤f51:sdn控制器依据openflow协议向所有的所述ovs下发一条流表规则a,所述流表规则a的内容是将收到的邻居学习请求报文上送到sdn控制器;

步骤f52:ovs收到router或者vnf发来的邻居学习请求报文后,将邻居学习请求报文上送到sdn控制器;

步骤f53:sdn控制器收到的邻居学习请求报文后,结合收到邻居学习请求报文的ovs的mac地址,构造邻居学习应答报文;邻居学习应答报文中封装的mac地址为收到邻居学习请求报文的ovs的mac地址;如果有多个ovs收到了同一个邻居学习请求报文,则sdn控制器根据负载均衡原则选择其中一个ovs的mac地址进行邻居学习应答报文封装;

步骤f54:依据openflow协议,sdn控制器向步骤f52中收到邻居学习请求报文的所述ovs下发一条流表规则b,所述流表规则b的内容是将sdn控制器下发的邻居学习应答报文转发给收到邻居学习请求报文的ovs;

步骤f55:sdn控制器依据openflow协议将步骤f53中构造的邻居学习应答报文发给步骤f52中收到邻居学习请求报文的ovs;

步骤f56:ovs将sdn控制器下发的邻居学习应答报文转发给发起请求的router或者vnf;

步骤f57:收到sdn控制器构造的邻居学习应答报文的router或者vnf学习到步骤f53中收到邻居学习请求报文的所述ovs接口的mac地址。

需要说明的是,通过上述改进,所述流表规则a、流表规则b是sdn控制器下发到ovs中的引流规则,由sdn控制器程序进行计算。下面对引流规则进行简要说明:

sdn模型应用了网络控制面与转发面分离的思想,控制器是控制主体,ovs是转发主体。控制器通过openflow协议集中控制所有的ovs,ovs则分散在多台物理主机上,数据报文到达ovs时,ovs会依据控制器下发的流表进行数据处理和转发。本文中的所有引流规则,都是指的控制器生成的流表规则。流表规则会被下发到多个ovs上,才能真正起到指引数据转发的作用。controller通常是一个framework,提供了实现应用逻辑的基础组件,但应用逻辑本身还是要controller使用者自己编程完成。本文中的接入规则和引流规则计算,都是用户逻辑,需要在controller提供的framework之上编程完成。

本实施例的步骤实现方法是在sdn控制器和ovs上,邻居学习报文的请求和应答是在ovs和router/vnf之间。通过流表规则实现arp代理,如果是ipv6网络,则实现nd协议代理。所述arp协议,即地址解析协议,是根据ip地址获取物理地址的一个tcp/ip协议;所述nd协议是ipv6邻居发现,是一组确定邻居节点之间关系的消息和过程。达到的效果是,router或vnf发送到ovs的邻居协议报文请求被上送到sdn控制器上,sdn控制器回复ovs相应接口的mac地址,达到私有云网络与传统网络模型实例的对接,使得数据可以送入ovs进行sdn规则处理,实现私有云网络中接入规则的计算和下发。具体过程为:

sdn控制器依据openflow协议向所有的所述ovs下发一条流表规则a,所述流表规则a的内容是将收到的邻居学习请求报文上送到sdn控制器。ovs收到router或者vnf发来的邻居学习请求报文后,依据流表规则a将邻居学习请求报文上送到sdn控制器。sdn控制器收到的邻居学习请求报文后,结合收到邻居学习请求报文的ovs的mac地址,构造邻居学习应答报文。

邻居学习应答报文中封装的mac地址为收到邻居学习请求报文的ovs的mac地址,如果有多个ovs收到了同一个邻居学习请求报文,则sdn控制器根据负载均衡原则选择其中一个ovs的mac地址进行邻居学习应答报文封装。

依据openflow协议,sdn控制器向收到邻居学习请求报文的所述ovs下发一条流表规则b,所述流表规则b的内容是将sdn控制器下发的邻居学习应答报文转发给收到邻居学习请求报文的ovs。sdn控制器依据openflow协议将构造的邻居学习应答报文发给收到邻居学习请求报文的ovs。

ovs将sdn控制器下发的邻居学习应答报文转发给发起请求的router或者vnf。收到sdn控制器构造的邻居学习应答报文的router或者vnf学习了收到邻居学习请求报文的所述ovs接口的mac地址。

本实施例的其他部分与上述实施例相同,故不再赘述。

实施例7:

本实施例在上述实施例的基础上做进一步优化,如图1-图2所示,所述步骤f6具体包括以下步骤:

步骤f61:计算引流规则时,sdn控制器输入用户配置的引流规则d和步骤f3中维护的网络拓扑图,用户数据报文通过router进入私有云;

步骤f62:sdn控制器解析用户配置的引流规则d,得到要匹配的字段和用户数据报文要经过的设备路径;

步骤f63:sdn控制器为路径上的每个ovs计算流表规则c,每个所述ovs在设备路径中出现一次对应生成一条流表规则cn;所述流表规则cn包括报文匹配内容、路径上下一个设备接口的mac地址以及mac地址的改写规则;改写mac地址的原因是ovs要去适应与所述ovs连接的vnf和bridge的收发包原则;

步骤f64:sdn控制器根据openflow协议将流表规则cn下发给路径上对应的ovs,指引用户数据报文的转发和改写;

步骤f65:此时router已学习到步骤f52中收到邻居学习请求报文的所述ovs的mac地址,router将用户数据报文转发给所述ovs;

步骤f66:收到router发来的用户数据报文的ovs根据步骤f64中对应下发的流表规则cn进行用户数据报文的匹配、改写以及转发;

步骤f67:当用户改变引流策略时,sdn控制器自动重新计算和下发所有的引流规则;当某个vnf节点发生迁移时,网络拓扑图会发生动态变化,sdn控制器自动重新计算所有的引流规则并下发;

所述步骤f7具体包括以下步骤:私有云完成用户数据报文的匹配、改写以及转发后,将用户数据报文返回给router。

需要说明的是,通过上述改进,

计算引流规则时,有两个输入:一是步骤f3中维护的网络拓扑图,二是用户配置的引流规则d;所述网络拓扑图是具有根节点的树结构,所述树结构中以所述bridge为主干,所述ovs为bridge的枝叶节点,所述vnf为ovs的枝叶节点。用户配置的引流规则d的格式是:{匹配某些报文字段,将符合匹配规则的报文依次交给某些vnf处理},例如:{匹配目的地址是192.168.34.1的报文,将符合匹配规则的报文依次交给vnf2,vnf1,vnf4,vnf3处理}。所谓引流规则计算,实际工作是把用户配置的引流规则,转化成多条ovs上的流表规则cn。sdn控制器解析用户配置的引流规则d,得到要匹配的字段和要经过的设备路径,比如,如图2所示,对应的解析结果为:匹配目的ip地址192.168.34.1,要经过的设备路径依次为:

ovs2->ovs1->vnf2->ovs1->vnf1->ovs1->ovs2->vnf4->ovs2->vnf3->ovs2,这个设备路径包括vnf和ovs,是根据网络拓扑图得到的。

根据上述解析得到设备路径,为路径上的每个ovs计算流表规则cn,每个ovs在设备路径中出现一次对应生成一条流表规则cn,某个ovs可能在路径中出现多次,所以sdn控制器计算得到的每个ovs的流表规则cn可能是多条。

如果有多个用户配置引流规则d,则sdn控制器会收到多条不一样的引流规则dn,从而产生多条不一样的设备路径,这样也会导致sdn控制器计算得到的每个ovs的流表规则cn为多条。

流表规则cn包含3个部分:一是报文匹配内容,比如匹配目的ip地址,可以匹配ip五元组信息中任意内容的组合加上用户数据报文输入接口;二是路径上下一个设备接口的mac地址;三是mac地址改写规则,改写mac地址的原因是ovs要去适应vnf和bridge的收发包原则;比如设备路径为:

ovs2->ovs1->vnf2->ovs1->vnf1->ovs1->ovs2->vnf4->ovs2->vnf3->ovs2,ovs2上某条流表规则cn的内容为:{匹配与vnf4相连接口发来的报文,匹配内容为目的ip是192.168.34.1,匹配成功后将报文转发到与vnf3相连的接口,转发的报文目的mac地址改写为vnf3的mac地址}。

sdn控制器根据openflow协议将生成流表规则cn下发给设备路径上的对应的ovs,以指引用户数据报文的转发和改写。router已学习到收到邻居学习请求报文的ovs的mac地址,因此可以将用户数据报文转发给这个ovs。ovs收到router发来的用户数据报文后,根据下发的流表规则cn进行报文匹配、改写以及转发。当用户改变引流规则d的策略时,sdn控制器自动重新计算和下发所有的引流规则;当某个vnf节点发生迁移时,网络拓扑会发生动态变化,sdn控制器自动重新计算所有的引流规则并下发。

私有云完成用户数据报文的匹配、改写以及转发后,将用户数据报文返回给router,实现私有云自动处理用户数据报文的方法。

本实施例的其他部分与上述实施例相同,故不再赘述。

以上所述,仅是本发明的较佳实施例,并非对本发明做任何形式上的限制,凡是依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化,均落入本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1