一种硬件资源定制方法及装置转让专利

申请号 : CN201310193790.5

文献号 : CN103580909A

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 王锋

申请人 : 杭州华三通信技术有限公司

摘要 :

本发明提供一种硬件资源定制的方法及装置,应用于网络设备上,用于与网络中的控制器配合,其中该方法包括:在收到来自控制器的资源收集请求消息后向控制器发送收集响应消息,并在该收集响应消息中携带本设备硬件功能的原始资源分配表,其中该资源分配表包括多个硬件功能标识,与每个硬件功能对应的资源大小以及资源共享标识,其中资源共享标识用于表征可进行资源共享的硬件功能集合;接收来自控制其的资源定制请求消息,并从该消息中获取二次资源分配表;根据二次资源分配表重新配置硬件功能的资源大小。相对于现有技术而言,本发明能够极大程度地发挥硬件的各种资源,在SDN网络中,其技术效果更佳突出。

权利要求 :

1.一种硬件功能管理装置,应用于网络设备上,用于与网络中的控制器配合,该装置包括收集响应单元、定制响应单元以及硬件管理单元,其特征在于:收集响应单元,用于在收到来自控制器的资源收集请求消息后向控制器发送收集响应消息,并在该收集响应消息中携带本设备硬件功能的原始资源分配表,其中该资源分配表包括多个硬件功能标识,与每个硬件功能对应的资源大小以及资源共享标识,其中资源共享标识用于表征可进行资源共享的硬件功能集合;

定制响应单元,用于接收来自控制其的资源定制请求消息,并从该消息中获取二次资源分配表;

硬件管理单元,用于根据二次资源分配表重新配置硬件功能的资源大小。

2.如权利要求1所述的装置,其特征在于:所述定制响应单元,进一步用于判断自身系统是否能够支持该二次资源分配表,如果是则将该二次分配表确定为经过确认的二次资源分配表转硬件管理单元处理;否则在返回给控制器的定制响应消息携带自身可支持的且与该二次资源分配表最接近的资源分配表;并在接收到控制器的定制确认消息后将该最接近的资源分配表确定为经过确认的二次分配表,转硬件管理单元处理;

硬件管理单元,硬件管理单元进一步用于根据经过确认的二次资源分配表,重新配置硬件功能的资源大小。

3.如权利要求2所述的装置,其特征在于:定制响应单元,在判断自身系统是否能够支持该二次资源分配表之前,先判断自身系统是否能够支持二次资源分配功能,如果是则继续,否则在返回给控制器的定制响应消息携带出错信息。

4.如权利要求1所述的装置,其特征在于,硬件管理单元进一步用于判断新配置生效是否需要重启系统,如果是则重新启动系统使其生效。

5.如权利要求1所述的装置,其特征在于,所述收集响应消息中携带有多个不同的原始资源分配表。

6.如权利要求1所述的装置,其特征在于,所述资源为表项资源。

7.一种硬件功能管理方法,应用于网络设备上,用于与网络中的控制器配合,其特征在于,该方法包括:步骤A、在收到来自控制器的资源收集请求消息后向控制器发送收集响应消息,并在该收集响应消息中携带本设备硬件功能的原始资源分配表,其中该资源分配表包括多个硬件功能标识,与每个硬件功能对应的资源大小以及资源共享标识,其中资源共享标识用于表征可进行资源共享的硬件功能集合;

步骤B、接收来自控制其的资源定制请求消息,并从该消息中获取二次资源分配表;

步骤C、根据二次资源分配表重新配置硬件功能的资源大小。

8.如权利要求7所述的方法,其特征在于:所述步骤B进一步包括:

判断自身系统是否能够支持该二次资源分配表,如果是则将该二次分配表确定为经过确认的二次资源分配表;否则在返回给控制器的定制响应消息携带自身可支持的且与该二次资源分配表最接近的资源分配表;并在接收到控制器的定制确认消息后将该最接近的资源分配表确定为经过确认的二次分配表;

所述步骤C具体为:根据经过确认的二次资源分配表,重新配置硬件功能的资源大小。

9.如权利要求8所述的方法,其特征在于:所述步骤B进一步包括:

在判断自身系统是否能够支持该二次资源分配表之前,先判断自身系统是否能够支持二次资源分配功能,如果是则继续,否则在返回给控制器的定制响应消息携带出错信息。

10.如权利要求7所述的方法,其特征在于,硬件管理单元进一步用于判断新配置生效是否需要重启系统,如果是则重新启动系统使其生效。

11.如权利要求7所述的方法,其特征在于,所述收集响应消息中携带有多个不同的原始资源分配表。

12.如权利要求7所述的方法,其特征在于,所述资源为表项资源。

说明书 :

一种硬件资源定制方法及装置

技术领域

[0001] 本发明涉及数据通信领域,尤其涉及一种硬件资源定制的方法及装置。

背景技术

[0002] 传统的网络架构已经越来越不能满足当前企业、运营商以及用户的需求。在报文的转发上,设备需要依赖复杂的路由算法。而在更为重要的安全以及流量控制等方面,传统的网络依赖于网络设备特性的不断完善,每当出现新的安全需求或流量控制需求,网络设备很可能需要进行软件升级。
[0003] 当前软件定义网络(Software Defined Networking,SDN)这一技术潮流正在颠覆网络架构以及技术体系的理解。在SDN网络架构中,业务控制平面与业务转发平面彻底分离,网络的管理和控制在逻辑上集中到一起,底层的网络基础从应用中抽象出来。由此,企业和运营商获得对自身网络前所未有的可编程性,自动化和控制能力,使他们很容易适应变化的业务需求,建立高度可扩展的弹性网络。
[0004] OpenFlow就是目前SDN网络架构中最流行的一种技术体系。在OpenFlow的技术架构中,主角是控制器(Controller),配角是OpenFlow网络设备,通常是OpenFlow交换机。OpenFlow网络设备在自身内部维护一个流表(FlowTable流表),在执行数据报文转发的时候,其只按照FlowTable流表进行转发,FlowTable流表本身的生成、维护、下发完全由外置的Controller来实现。也就是说,网络设备转发报文的时候先查询FlowTable流表,如果命中一条表项,则按照表项中的出接口进行转发即可;如果没有命中,则请求Controller来下发一个新的表项来指导其转发。在这样的技术架构下,管理者可以通过Controller任意定义各种数据报文的转发,不再受限于传统各种网络协议的限制,也不会受制于网络设备功能应用的限制。
[0005] 值得注意的是,这里所说的FlowTable流表有别于传统的会话流表,其并非传统技术中狭义的IP五元组或者IP三元组。事实上OpenFlow1.0协议中定义的了包括端口号、VLAN、二层到四层等信息的数十个关键字,但是每个字段都是可以通配的,网络的运营商可以决定使用何种粒度的流,比如运营商只需要根据目的IP进行路由,那么流表中就可以只有目的IP字段是有效的,其它全为通配。

发明内容

[0006] 有鉴于此,本发明提供一硬件功能管理装置,应用于网络设备上,用于与网络中的控制器配合,该装置包括收集响应单元、定制响应单元以及硬件管理单元,其中:
[0007] 收集响应单元,用于在收到来自控制器的资源收集请求消息后向控制器发送收集响应消息,并在该收集响应消息中携带本设备硬件功能的原始资源分配表,其中该资源分配表包括多个硬件功能标识,与每个硬件功能对应的资源大小以及资源共享标识,其中资源共享标识用于表征可进行资源共享的硬件功能集合;
[0008] 定制响应单元,用于接收来自控制其的资源定制请求消息,并从该消息中获取二次资源分配表;
[0009] 硬件管理单元,用于根据二次资源分配表重新配置硬件功能的资源大小。
[0010] 本发明还提供一种硬件功能管理方法,应用于网络设备上,用于与网络中的控制器配合,其中该方法包括:
[0011] 步骤A、在收到来自控制器的资源收集请求消息后向控制器发送收集响应消息,并在该收集响应消息中携带本设备硬件功能的原始资源分配表,其中该资源分配表包括多个硬件功能标识,与每个硬件功能对应的资源大小以及资源共享标识,其中资源共享标识用于表征可进行资源共享的硬件功能集合;
[0012] 步骤B、接收来自控制其的资源定制请求消息,并从该消息中获取二次资源分配表;
[0013] 步骤C、根据二次资源分配表重新配置硬件功能的资源大小。
[0014] 相对于现有技术而言,本发明能够极大程度地发挥硬件的各种资源,在SDN网络中,其技术效果更佳突出。

附图说明

[0015] 图1是本发明一种实施方式中硬件资源定制装置的逻辑结构图。
[0016] 图2是本发明一种实施方式中硬件资源定制方法的处理流程图。

具体实施方式

[0017] 如前所述,在SDN网络中,网络设备的业务就是查表转发,与现有技术最大的不同是,其不需要自己去动态学习如何生成这个流表。因此,网络设备不再象现有技术中那样需要在控制层面具有大量的软件功能,比如路由学习以及安全处理这些极度复杂的软件功能等。网络设备在控制层面仅仅需要完成与控制器之间的交互,接受控制器管理,完成基本配置下发等简单的控制层面工作。为了安全起见,通常网络设备与控制器之间通常会建立安全连接,比如流行的SSL连接等。在连接建立之后,控制器和网络设备会交互一些能力参数。一般情况下控制器主动向网络设备发送REQUEST消息来获取网络设备的能力参数,而网络设备回应REPLY消息来回应控制器。具体回应的内容可以参考以下示例:
[0018]
[0019]
[0020] 然而,当前的控制器与网络设备之间的能力信息上的交互机制过于呆板,其最大的问题是难以最大限度挖掘网络设备的硬件能力,其次控制器只能够获取到当前设备固定的硬件能力集,也就是网络设备告诉控制器当前设备的硬件能力集,控制器也只能根据这个能力集来部署和使用网络设备。
[0021] 本发明通过改进SDN网络中控制器与网络设备的能力定制方法来解决上述问题。以软件实现为例,本发明提供一种硬件资源定制方法及装置,其中该定制装置作为逻辑装置运行在网络设备上,与控制器相配合,协助网络管理者完成硬件资源的二次定制。作为该逻辑装置运行的载体,网络设备的硬件环境通常至少都包括CPU、内存以及非易失性存储器来支持上述逻辑装置的运行。当然,网络设备还包括很多本发明需要对其资源进行二次定制的业务硬件。请参考图1,所述定制装置包括收集响应单元、定制响应单元以及硬件管理单元。请参考图1以及图2,上述两个装置在运行过程中交互流程包括以下步骤。
[0022] 步骤10,控制器向网络设备发送资源收集请求消息;
[0023] 步骤11,在收到资源收集请求消息后,收集响应单元相应发送收集响应消息,并在该响应消息中携带本网络设备硬件功能的原始资源分配表;
[0024] 步骤12,控制器向网络设备发送资源定制请求消息,并在该资源定制请求消息中携带二次资源分配表;
[0025] 步骤13,在收到资源定制请求消息后,定制响应单元先判断自身系统是否能够支持二次资源分配功能,如果是则继续步骤14;否则在返回给控制器的定制响应消息携带出错信息,控制器只能接受网络设备上报的一个或者多个固定的原始资源分配表。
[0026] 步骤14,判断系统是否支持该资源定制请求消息所携带的二次资源分配表,即按照二次资源分配表中对各种资源的需求对硬件资源进行划分定制;如果否转步骤15,如果是则将该资源定制请求消息携带的二次资源分配表作为经过确认的二次资源分配表并转步骤18处理;
[0027] 步骤15,定制响应单元确定自身系统可支持的且与定制请求中该二次资源分配表最接近的资源分配表,并将该最接近的资源分配表携带在定制响应消息中发送给控制器;
[0028] 步骤16,在收到定制响应消息后,控制器发送定制确认消息给该网络设备以确认该最近接的资源分配表;
[0029] 步骤17,定制响应单元收到定制确认消息后,将该最接近的资源分配表确定为经过确定的二次资源分配表,转步骤18处理;
[0030] 步骤18,硬件管理单元根据经过确认资源二次资源分配表,重新配置硬件功能的资源大小,并判断是否需要重启系统,如果是则执行系统重启。
[0031] 在现有技术中,网络设备通常只能支持固定的系统模式,在固定的系统模式下各种硬件功能(也可以理解为一个逻辑意义上的功能模块)可以支配的资源是固定的,这在传统网络体系中是具有实际意义的,因为网络设备并不知道要部署在什么样的网络中,哪些资源可以使用、哪些资源会闲置是网络设备制造商无法预知的,因此只能根据开发经验和组网经验做固定硬件资源分配。请参考表1(仅仅是示例性教导,并无实际业务意义),以表项资源为例,网络设备的硬件表项总的大小在其出厂之后就是固定的大小的,但是这些表项资源事实上是可以通过在系统控制层面引入硬件资源分配功能来使其可以分配给不同的硬件功能来使用,从而形成多种功能的不同资源分配集合,形成多种灵活系统模式,从而适应于不同的网络组网中,本发明利用这一特点以寻求在SDN网络中极大程度地发挥网络设备的在硬件性能。
[0032]
[0033]
[0034] 表1
[0035] 在从传统网络向SDN演进的过程中,网络设备是不断替换和更新的,这其中还要考虑兼容的问题。就好像从IPv4向IPv6的演进过程一样,为保护既有网络投资,新技术和老技术共存是长期性的。为了确保和当前网络兼容,支持SDN(比如OpenFlow)的网络设备除了支持FlowTable流表之外,还需要支持当前传统二三层的网络功能,例如ARP表项,MAC表项等,这样可以最大限度的确保OpenFlow与传统网络技术的融合和迁移。在网络设备上,FlowTable流表表项和传统ARP表项,MAC表项等很可能都是可以共享硬件资源的。但是不同用户在组网时对于OpenFlow的需求很可能是不同的,例如一种情况是,大部分报文流量可能需要根据OpenFlow建立的FlowTable流表进行转发,只有少部分报文流量按照传统二三层的网络功能进行转发;也有一种情况是,大部分的报文流量以传统二三层的网络功能进行转发,只有少部分报文流量是根据OpenFlow建立的FlowTable流表进行转发。
这两种情况对于网络设备的能力定制要求不同,前者要求设备在初始能力定制时,多划分一些硬件资源给OpenFlow的FlowTable流表,而后者则要求多划分一些硬件资源给传统的ARP表项,MAC表项。
[0036] 表1所示是一个既支持SDN又支持传统网络架构的三层交换机的硬件功能原始资源分配表。其中Type(类型)一列,用来表示具体类型的硬件功能,包括各个硬件功能标识,例如ARP以及ND都是业界通用的硬件功能,同样的MAC(可理解为MAC地址学习)以及ACL也是非常通用的硬件功能。Openflow流表则是指代SDN技术中的流转发硬件功能。Type列中的硬件功能通常是控制器和网络设备都能支持识别,如不能够识别的,则在本发明中可以不关心这种功能。
[0037] Length(长度)表示该硬件功能的表项长度规格,也就是一个表项需要占用的长度,这通常是厂商自定义的,比如说一个ARP表项需要占用4个字节,比如一个单播路由占用8个字节等。而规格数量则表示表项的大小,表示该硬件功能实际上初始分配有多少个对应规格的表项。因此规格数量与长度规格的乘积可以理解为该硬件功能所占用表项资源的具体大小。比如说表1中ARP功能所占用的表项资源大小64K×4B=256KB。在本发明中,为了允许控制器更加灵活地定制网络设备的系统模式,相应引入了共享标识,标识特定硬件功能集合表项资源是否可以与其他硬件功能共享,如果共享,与具体哪个硬件功能共享。比如说,参考表1,其中ARP、ND以及两个功能的共享标识相同,表中ARP和ND第一个二进制BIT显示为1,该BIT表明共享,而后面的7个BIT代表共享编码,ARP和ND硬件功能的共享编码都是7,表明这两个之间可共享各自的硬件资源。而MAC的显示为0,则表明不共享,独占128K×6B的资源。再比如,单播路由、组播路由、ACL以及Openflow流表四个硬件功能的表项资源是可以进行共享分配的。
[0038] 步骤10通常可以通过GET操作来实现,而11则是对GET操作的回应。通过步骤10和11的处理之后,控制器就可以知晓网络设备的原始资源分配表。所谓原始分配表可以理解为出厂默认的分配表,也可以理解为网络设备当前的分配表。在优选的方式中,设备制造商可以预先设置多个原始资源分配表,这些原始资源分配表可以对应到各种典型的系统模式,比如网络设备用做网关的IPv4优先模式,则ARP的表项资源则会更大一些。
[0039] 在本发明中,对于控制器而言,其需要知晓网络设备支持哪些硬件功能,有多少表项资源可以在哪几个硬件功能之间进行共享。通常资源请求消息是基于用户的指令发出的,在得到网络设备侧对应的收集响应消息的之后,控制器一侧就得到了表1,管理者可以访问控制器来得到表1的各项内容。管理者可以根据实际需要来重新分配各个硬件功能具体可以使用的表项资源。收集响应消息中的共享标识是管理者根据业务需要进行表项资源再分配的基础依据。此时管理者可以通过控制器来执行步骤12,步骤12通常可以通过SET操作来实现。比如说,管理者发现当前管理的网络设备并无任何IPv6的业务流量时,而IPv4业务量比较大,此时其可以将ND的64K的表项资源中的一部分分配给ARP。同样的道理,管理者如果发现网络中实际上没有组播业务或者组播业务量很小,此时管理者可以将组播路由这一功能下的表项资源分配给单播路由,或者分配给流转发功能。管理者在考虑了整个网络业务需求之后,可以定制出一个自身认为最为合理的二次资源分配表。
[0040] 管理者一旦确定二次分配方案之后,其可以通过控制器下发二次资源分配表,该二次资源分配表可以携带在资源定制请求消息中下发。网络设备一侧收到该消息之后可以先从该资源定制请求消息中获得二次资源分配表,比如表2那样的示例,在步骤13中,定制响应单元还可以先判断自身系统是否支持二次资源分配这项功能,如果支持则继续步骤14,如果不支持二次资源分配这项功能,则可以返回出错信息给控制器,控制器只能接受网络设备上报的一个或者多个固定的原始资源分配表,然后采用传统的方式来配置网络设备。然后通过步骤14(可理解为一种PUT操作)来判断网络设备自身系统是否支持该二次资源分配表,即按照二次资源分配表中对各种资源的需求对硬件资源进行划分定制。如果网络设备自身系统能够支持这样的分配方案,则可以将该二次资源分配表视为经过确认的二次资源分配表,也就是说该分配方案是控制器侧与网络设备侧都认可的一个分配方案。当然,在优选的实施方式中,管理者可能需要同时管理网络中来自多个厂商的大量网络设备,这些网络设备的开发与设计并非标准如一的,因此有可能会产生二次资源分配无法被网络设备执行的情况。请参考表2,比如说,假设管理者通过控制器下发的二次资源分配表中ARP的表项资源的规格数量为196K。对于ARP功能来说,其增加的表项资源大小为128K*4B=512KB,相应地,ND功能的表项资源则会减小512KB,即ND表项规格数量下降
512KB/16B=32K。然而假设196K这个规格数量超过了网络设备能够分配给ARP功能的最大表项值--128K,也就是说管理者的分配方案并不能够在网络设备上被实际实施,但对于这一点,管理者事先可能无法知晓,管理者只能从理论上看出ARP功能可以拥有196K这么多数量的表项资源,是否能够实际拥有可以由网络设备来确认。
[0041]
[0042] 表2
[0043] 网络设备一侧一旦发现这种自身无法支持的情况可以通过定制响应消息来报告控制器。在简单的实施方式中如步骤13,网络设备并不需要进一步与控制器协商,而只是简单地通过定制响应消息携带出错信息(比如超出能力范围信息)即可。在优选的方式中如步骤14,网络设备可以根据原始资源分配表计算出一个自身系统可以支持且与二次分配表最接近的资源分配表,然后将该最接近的资源分配表发送给控制器,请参考表3示例。
[0044]
[0045] 表3
[0046] 管理者通过控制器接收到最接近的资源分配表之后,其可以判断网络设备发送的最接近的资源分配表是否可以被其接受,如果不能接受,管理者可以重新调整分配方案,再次下发一个新的二次资源分配表。如果这个最接近的资源分配表是其可以接受的,则可以发送定制确认消息(可理解为一种PUT ACK操作)给网络设备。网络设备收到该确认消息之后,可以将最接近的资源分配表确定为经过确认的二次分配表来处理,也就是说双方协商成功了。
[0047] 经过以上处理之后,如果管理者合理操作,网络设备最终会得到一个经过控制器和网络设备确认的二次资源分配表。然后网络设备可以按照表3重新配置各个硬件功能的表项资源。完成配置之后,网络设备可以进一步判断这样的配置是否要重启系统,如果是则向控制器通告后重新启动系统,让新的配置生效。
[0048] 以上所述仅为本发明的较佳实施例而已,并不用以限制本发明,凡在本发明的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本发明保护的范围之内。