CN108737150A - 承诺访问速率管理方法、业务板及主控板 - Google Patents

Abstract

本申请提供了一种承诺访问速率管理方法，应用于分布式网络设备上，该方法包括：接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项，在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。本申请上述方案能更好地适应分布式网络设备的架构。

Description

承诺访问速率管理方法、业务板及主控板

技术领域

本申请涉及网络通信技术，特别涉及QoS CAR管理方法、业务板及主控板。

背景技术

QoS(Quality of Service，服务质量)技术是解决网络延迟和阻塞等问题的一种技术。对于一些关键应用以及对时延敏感的多媒体应用，QoS技术的作用非常显著。当网络过载或拥塞时，QoS技术可以有效降低延迟或大幅度降低关键报文被丢弃的可能。更多关于QoS的介绍可以参考互联网工程任务组IETF发布的标准文档RFC 3644。

QoS CAR(Commit Access Rate，承诺访问速率)技术是在QoS技术基础上发展出来的一种技术。它的典型作用是基于承诺访问速率对进入某一网络的某类流量进行监管，例如限制HTTP类流量不能占用超过10Mbps。但是QoS CAR技术在分布式网络设备上的实施仍然面临各种难题。

发明内容

本申请提供了一种承诺访问速率管理方法，应用于分布式网络设备的主控板上，该分布式网络设备还包括一个或者多个业务板；该方法包括：

接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

本申请还提供了一种承诺访问速率管理方法，应用于分布式网络设备的业务板上，该分布式网络设备还包括主控板；该方法包括：

统计本板与某流量特征对应的流量接收速率TAR；

根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板。

本申请还提供了一种承诺访问速率管理方法，应用于分布式网络设备，其中该分布式网络设备包括主控板以及一个或多个业务板，所述方法包括：

业务板统计本板与某流量特征对应的流量接收速率TAR；

业务板根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

业务板在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

业务板在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板；

主控板接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

主控板在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

主控板接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

本申请支持各个业务板动态调整自身管理的承诺访问速率，从而更加适应分布式网络设备的架构特点。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1是一种分布式设备QoS CAR处理过程示意图。

图2是另一种分布式设备QoS CAR处理过程示意图。

图3是本申请一个例子中一种分布式设备结构图。

图4是本申请一个例子中主控板或业务板基本硬件架构图。

图5a是本申请一个例子中主控板一侧承诺访问速率管理方法流程图。

图5b是本申请一个例子中业务板一侧承诺访问速率管理方法流程图。

图6是使用承诺访问速率管理方法后图2的变化示意图。

图7是本申请另一个例子中承诺访问速率管理方法流程图。

图8是本申请一个例子中趋势算法流程图。

图9a是本申请一个例子中趋势算法部分流程图。

图9b是本申请一个例子中趋势算法另一部分流程图。

具体实施方式

QoS CAR技术可以理解为针对指定流量速率的监管，降低流量突发导致流量的实际访问速率(Traffic Access Rate，TAR)持续超过承诺访问速率，因此承诺访问速率也可以理解为监管的基准速率。QoS CAR技术在分布式网络设备中应用通常会面临挑战。与集中式网络设备不同的是，在分布式网络设备中，很多具有若干相同特征的报文(从网络设备的角度看是“流量”)可能会分散到多个业务板上处理，这些处理包括了QoS CAR处理以及其他安全处理等。在“流量分布处理”这个特点下，QoS CAR的具体实现将变得更加复杂。

请参考图1，假设分布式网络设备的管理员想针对HTTP类流量的速率进行QoS CAR处理，该管理员期望网络设备的全局承诺访问速率(Global CAR，GCAR)是300Mbps(以下无特殊说明，M表示Mbps)。也就是管理员的期望是：无论进入网络设备的流量速率大小是多少，经过网络设备的QoS CAR处理后，其结果不超过300M(或者与300M非常接近的某个数字)。

在图1中，假设网络设备有三个业务板，分别为业务板102a、业务板102b以及业务板102c，流量速率在QoS CAR处理前是600M，如前所述，流量会被分发到各个业务板上去处理。在图1中，600M速率的流量中有400M在业务板102a上处理，150M在业务板102b上，50M在业务板102c上处理。经过各个业务板QoS CAR处理后，业务板102a出来的流量速率被限制在300M，业务板102b出来的流量速率是150M，业务板102c出来的流量速率是50M，实际的结果是300M+150M+50M＝500M，这显然并不符合管理员期望的GCAR，即300M的速率。

请参考图2，对于图1的问题，一种典型的处理方式针对分布式网络设备部署有针对性的QoS CAR机制。在图2中，考虑到管理员期望的GCAR是300M，而网络设备有三个业务板。此时可以将300M的监管任务平均分配到三个业务板上去执行，即每个业务板承担100M的监管任务。经过这样的分配后，三个业务板的本地承诺访问速率(Local CAR，LCAR)都是100M，此时400M的流量进入业务板102a，经过业务板102a的QoS CAR处理后出来的流量速率是100M。同样的道理，此时150M的流量经过业务板102b处理后出来的也是100M，而50M的流量经过业务板102c处理后出来的是50M。从网络设备出来的总流量速率是100M+100M+50M＝250M。这一流量速率低于GCAR，即300M，其导致的结果是流量速率监管过度，导致条件允许的情况下却无法满足对于用户的速率承诺。

如果进入到业务板102a的流量是300M，进入业务板102c的流量是150M，那么此时出来的总速率将变成300M，符合管理员的预期，然而这是理想的情况，用户的流量从哪个业务板进入通常是难以控制的。实际上图2中的示例时常发生，这是因为流量的分布相当复杂当前流量速率大小可能相差很大。在某段时间内，指定流量可能在某个业务板上的速率很高，而在其他业务板上速率可能很低；在其他时间段内，这种状况可能又反过来。

请参考图3、图4、图5a以及图5b，本申请提供一种承诺访问速率管理方法以及实施该方法的分布式网络设备300。所述分布式网络设备300包括主控板301、若干业务板302a-302c以及将主控板301与业务板302(以下无特殊说明，302表示某一个业务板)相互连接的交换矩阵(Switch Fabric)303。交换矩阵303作为主控板301以及业务板302a-302c之间双向通信的内部通道。

请参考图4，主控板301和业务板302可以采用相同的基础硬件架构，包括处理器401、非易失性存储器402、通信总线403以及网络接口404。除了相同的基础硬件架构外，主控板301与业务板302的硬件环境可能有较大差异。比如说处理器的规格可能有较大差异，再比如说，相对于主控板301而言，业务板302可能包括转发芯片等更多种类的硬件。另外，各个业务板302之间的硬件也可能存在差异，这些差异在本申请中不再详细描述，此为本领域普通技术人熟悉的技术知识。

主控板301通常完成控制层面的处理，比如通过路由协议计算路由转发表项，将计算出来的表项下发到各个业务板302，将ACL规则或者QoS CAR策略等下发到业务板。简而言之，主控板301的主要作用就像指挥官一样，告知各个业务板302a-302c如何对流量进行数据层面的处理。这些处理可以包括QoS处理、NAT处理、隧道处理以及安全处理等等。当然在其他例子中，业务板302也可能在主控板301的控制下参与少量控制层面的处理工作，本领域普通技术人员可以参考已有技术的记载，此处不再详细讨论。

本申请所述承诺访问速率管理方法通过主控板301与业务板302a-302c的配合实现。主控板301或者业务板302在配合实现上述方法时，可以通过自身的处理器401从存储器402中读取计算机可读指令加以运行来实现。图4中虚线示意出的承诺访问速率管理逻辑可以理解为若干计算机可读指令的集合。

请参考图5a，在主控板301一侧，所述QoS CAR管理方法包括：

步骤501，接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

步骤502，在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

步骤503，接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

请参考图5b，在业务板302一侧，所述QoS CAR管理方法包括：

步骤511，统计本板与某流量特征对应的流量接收速率TAR；

步骤512，根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

步骤513，在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

步骤514，在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板。

通过图5a以及图5b的流程可以看出，其可以有效地缓解图2中的问题。在使用本申请上述方案后，图2中的示例可以变化为图6更加合理的示例。针对某个流量特征，相对于图2中各个业务板的LCAR均为固定的100M，图6中各个业务板的LCAR可以动态变化。对于TAR较大的业务板，比如业务板102a以及业务板102b，其很快会发现TAR相对于本板的LCAR来说呈现上升趋势，于是可以向主控板发出LCAR上调申请。而对于业务板102c这样的流量比较少的业务板来说，其可以及时感知到本板的TAR相对于本板的LCAR呈现下降趋势，于是及时地将LCAR降低，并通知主控板。通过主控板将降低的速率释放到TAR更高的业务板102a和业务板102b上来。经过这样的动态处理后，由于LCAR的动态变化，最终图6中经过三个业务板的QoS CAR处理后的流量速率分别是130M，120M以及50M，其总和刚好是300M，符合管理员的监管预期。需要注意的是，步骤501和步骤503之间没有严格的时间顺序关系。以下通过更多的例子结合更多的细节描述来阐述本申请。

请参考图7以及图8，以下通过更为详细的例子来描述主控板301与业务板302之间配合的过程。

在步骤701，主控板301接收并保存来自管理侧的QoS CAR配置信息。在这个例子中，QoS CAR配置信息可以包括策略ID、流量特征、全局承诺访问速率GCAR。请参考表1的示例，配置信息可以以表项的形式下发下来。表1中策略ID是一条QoS CAR配置的标识，与流量特征通常是对应的。流量特征也可以称为报文特征，通常是报文的某个字段或者某些报文字段的组合，比如报文的源IP地址，或者目的端口或者报文的源IP地址以及目的IP地址的组合，这些组合中甚至可以包括报文应用层级的字段，这取决于业务板302是否支持解析和处理这些报文字段。以三元组为例，其可以是源IP地址(SIP)、目的IP地址(DIP)、以及协议类型(PT)。

所述GCAR是针对具有该流量特征的流量做出的速率监管要求。实际上表1表达的含义可以形象地理解为：针对满足表1流量特征的流量，请对该流量的TAR进行监管，保证经过QoS CAR处理之后的流量速率被限制为不超过最高承诺的500M。接下来主控板301将控制各个业务板302来实现这个速率监管目标。

表1

在步骤702，主控板301获取业务板302的数量，并基于业务板的数量来确定各个业务板302初始的LCAR。考虑到业务板302的数量可能变化，比如管理员插入更多新的业务板，或者拔掉某些业务板，因此主控板301可以实时获取所有可用的业务板302的数量，进而决定各个业务板302的初始LCAR。业务板ID是主控板301与业务板302之间交互的依据，帮助主控板区分各个与其交互的业务板302。接下来，主控板301可以基于业务板302的数量来确定如何给业务板302分配对应的初始LCAR。假设业务板302的数量是n，初始的情况下，可以让每个业务板302平均分配GCAR；也就是说初始各个业务板的LCAR＝GCAR/n。值得注意的是，在这个例子中，各个业务板302的LCAR的初始值可以由主控板301下发；但是在其他例子中，各个业务板302的LCAR的初始值可以是预先就配置好的一个数值，甚至可以在开发的过程中预先配置好；事实上这个初始值即便很小也可以很快因为动态的LCAR申请的机制达到一个合理的数值。

在这个例子中为了简化实现，也为了方便描述，引入速率步长(Unit Rate，UR)，比如10K或2M等，其大小可以由开发人员根据需要预定义，在后续例子中LCAR的一次上调或者一次降低的幅度为一个UR。也就是说，后续如果没有特殊说明，速率单位将是UR。假设UR大小被设定为10K，那么260K的速率就是26。同样的道理，GCAR以及LCAR等各个速率可以用UR的数量来表达。比如说，假设UR＝50K，GCAR＝500M，LCAR＝300M，那么GCAR＝10240，LCAR＝6144。由于速率调整幅度是UR的整数倍，而原始GCAR可能不是UR的整数倍，此时可以采用预定的误差规则，比如四舍五入或者向上取整的办法来处理这种情况。比如说上一个例子中，如果UR＝30K，采用向上取整的办法，此时主控板301实际保存GCAR可以表达为17067UR。同样的道理，LCAR也可以换算为UR的数量，此处不再赘述。值得注意的是，由于引入了误差规则，那么管理侧下发的原始GCAR与主控板301实际保存的GCAR可能存在些许误差，但事实上两者本质上是一致的，后者只是为了方便整除计算做出的简单调整。

在步骤703，主控板301可以使用上述管理侧下发的QoS CAR配置信息、各个业务板的初始LCAR在QoS表中创建相应的QoS表项。请参考表2的示例。在这个例子中，假设UR＝50K，GCAR＝500M，LCAR＝300M，各种速率被转换为UR的数量来表示。FCAR(Free CAR)表示可用的承诺访问速率，也就是一个表项中GCAR与各个业务板302的LCAR总和的差值，初始的时候可以为0。

表2(单位：UR＝50K)

如前所述，各个业务板302的LCAR的初始值可以由主控板301计算确定。在这个例子中，FCAR等于0，各个业务板的LCAR的初始值都被设置为大致相同，相当于大致均分了GCAR(此处考虑了预定的误差规则)。如果把单位换算为bps，此时GCAR的大小为500M，而业务板302a-302c的当前承诺访问速率都大致设置为500M/3，约等于167M。在设定好初始的LCAR之后，主控板301可以将表1和表2中的策略ID、流量特征以及各个业务板的初始LCAR分别对应下发给各个业务板302。其中策略ID(对应流量特征)可以方便主控板301和业务板302进行交互，方便双方知道上调或者降低速率是针对哪个QoS表项的。

步骤704，主控板301向各个业务板302下发QoS CAR执行表项，每个执行表项可以包括策略ID、流量特征以及各个业务板自身的LCAR。

步骤705，业务板302根据接收到的QoS CAR执行表项创建对应的缓存队列，根据流量特征将流量送到对应的缓存队列并执行QoS CAR处理。

在业务板302接收到QoS CAR执行表项后，可以根据其中的流量特征以及LCAR对经过本板符合上述流量特征的流量进行QoS CAR处理。在这个例子中，业务板302根据主控板301下发的策略ID创建相应的缓存队列。其中缓存队列是用来将进入本板的流量缓存起来以便后续处理或者统计。每个流量特征可以对应一个或者多个缓存队列，换而言之，也就是主控板指定的流量(通过流量特征反应)可以有自身专属的缓存队列。业务板302可以使用令牌桶技术针对该流量进行速率控制，针对指定的流量向令牌桶中投放的令牌的数量与该流量特征对应的LCAR通常是相对应的。更多使用令牌实现速率控制的细节可以参考已有技术实现。在其他例子中，本领域普通技术人员可以采用其他可能的技术方式来实现流量速率监管，本申请对此并无限制。

需要注意的是，进入业务板的流量可能有很多种，这些流量可能不会匹配到任何一个主控板下发的流量特征，那么这种流量就不需要QoS CAR处理；如果匹配到某个流量特征，则可以进入与之对应的缓存队列等待相应的速率监管处理。流量特征的匹配可以参考已有技术实现，比如ACL或者其他类似的数据报文分类技术。

步骤706，业务板302对进入缓存的流量进行统计得到该流量特征对应的TAR。

步骤707，业务板302根据预定趋势算法确定TAR相对于该流量特征对应的LCAR的变化趋势，如果变化趋势为上升，则执行步骤708，如果变化趋势为下降，则执行步骤709。

步骤708，业务板302向主控板301发出LCAR上调申请，转步骤710。

步骤709，业务板302降低本业务板的LCAR并通知主控板301，转步骤713。

请参考图8，在这个例子中，步骤706以及步骤707的具体实现可以包括：

步骤801，统计本板下一个预定周期内与该流量特征对应的TAR；该预定周期可以由开发人员根据经验设定，或者由管理员根据实际网络环境自由配置。

步骤802，判断TAR是否大于LCAR，如果是，转步骤803，否则转步骤804；

步骤803，判断TAR-LCAR是否大于或等于第一速率阈值(FRS)，若是，则确定变化趋势为上升趋势，然后返回步骤801；否则，直接返回步骤801；

步骤804，判断LCAR-TAR是否大于或者等于第二速率阈值(SRS)，若是，则确定变化趋势为下降趋势，然后返回步骤801；否则，直接返回步骤801。

请继续参考图8，针对上述趋势算法，可以根据需要对算法中FRS以及SRS进行调整，其中FRS与SRS可以相同，也可以不同。在一个典型的例子中，为了保障用户的流量得到及时处理，SRS可以设置得比FRS大，比如说FRS可以小于一个UR(如0.5UR)，甚至可以是最小的速率单位1bps，而SRS可以是UR的N倍，其中N为大于等于1的自然数。

在这个例子中，假设一个流量特征对应的TAR向上波动和向下波动的概率大致相同，那么SRS相对较大则意味着下降趋势被确认的概率将相对较小，同样的道理，FRS相对较小则意味着下降趋势被确认的概率将相对较大。在上面这个例子中，LCAR比TAR大，并且差值达到了一个UR，才会构成下降趋势，进而触发降低LCAR的操作。如果SRS设置的太小，下降趋势很容易满足，可能导致LCAR降低之后，TAR稍微增大一些就会导致变化趋势又变成了上升趋势，进而导致业务板302又发出LCAR上调申请。在流量速率小幅度频繁波动时，会导致频繁的LCAR上调和降低。

如前所述，由于FRS相对较小意味着上升趋势被确认的概率相对较大，这意味着业务板302在TAR刚刚超过LCAR的情况下，能够及时地向主控板发出上调LCAR的申请。如果LCAR长期小于TAR，则会导致缓存内的该流量特征对应的流量不断累积，进而可能导致部分流量被丢弃。而及时发出上调LCAR的申请可以有效降低缓存中流量被丢弃的可能性。

换个角度来说，在这个例子中，业务板302更加谨慎地降低自身的LCAR，同时又更加及时地申请上调自身的LCAR，这对于兼顾了对用户流量速率的承诺以及对TAR的合理监管。需要注意的是，以上仅仅是示例，在其他特殊的场景中，比如说监管比承诺优先的场景中，FRS与SRS的大小关系可能是相反的。

在这个例子中，步骤803以及步骤804中确定上升趋势或者下降趋势是基于同一个预定周期的。在其他例子中，确定上升趋势以及下降趋势可以采用不同的预定周期。请参考图9a以及图9b，此时，实现方案可以包括以下步骤：

在图9a中，步骤901，统计本板下一个第一预定周期内与该流量特征对应的第一TAR；该第一预定周期可以由开发人员根据经验设定，或者由管理员根据实际网络环境自由配置。

步骤902，判断第一TAR-LCAR是否大于或等于FRS，若是，则确定变化趋势为上升趋势，然后返回步骤901；否则，直接返回步骤901。

在图9b中，步骤903，统计本板下一个第二预定周期内与该流量特征对应的第二TAR；该第二预定周期可以由开发人员根据经验设定，或者由管理员根据实际网络环境自由配置。

步骤904，判断LCAR-第二TAR是否大于或等于SRS，若是，则确定变化趋势为下降趋势，然后返回步骤903；否则，直接返回步骤903。

在这个例子中，步骤901和步骤903是并行分别统计的，可以由两个不同的定时器控制分别统计两个预定周期内的第一TAR以及第二TAR，这个例子中，两个预定周期不同，如果两个预定周期相同则会回归到图8所示的例子中。在这个例子中，第二预定周期大于第一预定周期，其意义与第二速率阈值大于第一速率阈值是相似的。

第二预定周期相对较大意味着下降趋势被确认的概率相对较小，也就是说，相对降低了业务板302降低LCAR的频率。如果第二预定周期设置的太小，下降趋势更加容易满足，LCAR降低之后，若第二TAR很快增大又导致变化趋势又变成了上升趋势，进而导致业务板302又发出LCAR上调申请。在流量速率小幅度频繁波动时，会导致频繁LCAR上调和降低。

同样的道理，由于第一预定周期相对较小，则意味着上升趋势被确认的概率相对较大，这意味着业务板302可以更加及时地向主控板发出与该流量特征对应的LCAR上调申请。如果LCAR长期小于TAR，则会导致缓存内的流量不断累积，进而可能导致部分流量被丢弃，而及时发出上调LCAR的申请可以有效降低流量被丢弃的可能性。

步骤710，主控板301判断FCAR是否不等于0，若是，则转步骤712和步骤713，否则转步骤711。

步骤711，主控板301向业务板302发出拒绝申请通知，结束当前流程。

步骤712，主控板301通知业务板302该申请被接受，转步骤714。

步骤713，主控板301在QoS表中更新与该流量特征对应的业务板的LCAR以及FCAR。

步骤714，业务板302收到申请被接受的通知后，执行相应的上调操作，并更新与该流量特征对应的LCAR，结束当前流程。

仍然以表2为例，假设此时业务板302a发现该流量特征的TAR相对于本板当前LCAR来说的变化趋势为上升趋势，此时其可以向主控板301提出LCAR上调申请。主控板301收到该申请后，首先检查FCAR，如果FCAR等于0，则意味着，对于该流量特征来说，各个业务板的LCAR的总和已经等于GCAR，说明没有可以上调的余地，可以拒绝业务板302a的此次申请。业务板收到该申请之后，可以继续统计TAR直到下一个预定周期到达

从表2的示例可以看出，业务板302a的LCAR上调申请将会被拒绝。假设业务板302b确定该流量特征的TAR相对于当前对应的LCAR来说呈现下降趋势，此时其可以释放掉1个UR的速率，把当前LCAR更新为3413-1＝3412，然后通知主控板301。主控板接收到该通知后在表2中进行相应更新，将业务板302b的LCAR更新为3412，然后将FCAR加1，更新后的FCAR＝1。

经过一段时间之后，假设业务板302c确定流量的TAR相对于本板当前LCAR来说的变化趋势为上升趋势，此时其可以向主控板301提出LCAR上调申请。在步骤710，主控板301收到该LCAR上调申请后，首先检查FCAR，发现FCAR不等于0，则说明可以接受本次LCAR上调申请并通知302c。主控板301接受该申请后可以将FCAR减1，将302c的LCAR加1，更新后的302c的LCAR＝3415，更新后的FCAR＝0。而302c得到该通知后可以将自身的LCAR更新，更新后的LCAR为3415。业务板302a-302c经过一段较长时间的运行后，其可能反复地执行降低LCAR和LCAR上调申请的操作，每个业务板302的LCAR都可能发生较大的变化，此时表2可能更新为表3的示例。

表3(单位：UR＝50K)

其中GCAR使用掉的部分为各个业务板LCAR之和，即9734＝1088+4107+4539；剩余的就是FCAR，即10240-9734＝506。在FCAR数量较大的时候，说明该流量特征的TAR并不高，还没有达到GCAR，显然满足速率监管的要求，也满足速率承诺。此时如果该流量特征的TAR上升，无论这种上升来自哪个或者哪几个业务板302上速率的上升，这些业务板302很快就可以通过向主控板301发出LCAR上调申请，来满足这种流量速率上升的需求，直到FCAR＝0为止。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (32)

1.一种承诺访问速率管理方法，应用于分布式网络设备的主控板上，该分布式网络设备还包括一个或者多个业务板；其特征在于，该方法包括：

接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

2.根据权利要求1所述的方法，其特征在于，还包括：

接收管理侧下发的流量特征以及对应的全局承诺访问速率GCAR；

在QoS表中记录该流量特征对应的GCAR以及各个业务板的本地承诺访问速率LCAR；

将所述流量特征下发给各个业务板。

3.根据权利要求2所述的方法，其特征在于，还包括：

根据GCAR以及业务板数量确定各个业务板的初始LCAR，并将每个业务板的初始LCAR分别下发给各个业务板。

4.根据权利要求1所述的方法，其特征在于：其中LCAR一次上调或者一次降低的幅度为预定的速率步长UR。

5.一种承诺访问速率管理方法，应用于分布式网络设备的业务板上，该分布式网络设备还包括主控板；其特征在于，该方法包括：

统计本板与某流量特征对应的流量接收速率TAR；

根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板。

6.根据权利要求5所述的方法，其特征在于：

所述统计本板与某流量特征对应的TAR包括：统计本板下一个预定周期内所述流量特征对应的TAR；

所述预定趋势算法包括：

如果TAR大于LCAR且两者差值大于或等于第一速率阈值FRS，则确定变化趋势为上升趋势；

如果TAR不大于LCAR且两者差值大于或者等于第二速率阈值SRS，则确定变化趋势为下降趋势。

7.根据权利要求6所述的方法，其特征在于：

其中LCAR一次上调或者一次降低的幅度为预定的速率步长UR。

8.根据权利要求6所述的方法，其特征在于：所述SRS大于FRS。

9.根据权利要求8所述的方法，其特征在于：其中SRS大于或等于UR或为UR的N倍，N为大于1的自然数。

10.根据权利要求5所述的方法，其特征在于：所述统计本板与某流量特征对应的TAR包括：

统计本板下一个第一预定周期内与某流量特征对应的第一TAR以及下一个第二预定周期内与该流量特征对应的第二TAR；

所述预定趋势算法包括：

如果第一TAR大于LCAR且两者差值大于或等于第一速率阈值FRS，则确定变化趋势为上升趋势；

如果第二TAR不大于LCAR且两者差值大于或者等于第二速率阈值SRS，则确定变化趋势为下降趋势。

11.根据权利要求10所述的方法，其特征在于：所述第二预定周期大于所述第一预定周期。

12.根据权利要求5所述的方法，其特征在于：其中LCAR的初始值是主控板下发的。

13.根据权利要求5所述的方法，其特征在于：还包括：

接收主控板下发的流量特征，根据该流量特征对应的预设的本地承诺访问速率LCAR执行QoS CAR处理。

14.一种承诺访问速率管理方法，应用于分布式网络设备，其中该分布式网络设备包括主控板以及一个或多个业务板，所述方法包括：

业务板统计本板与某流量特征对应的流量接收速率TAR；

业务板根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

业务板在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

业务板在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板；

主控板接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

主控板在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

主控板接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

15.根据权利要求14所述的方法，其特征在于，还包括：

主控板接收管理侧下发的流量特征以及对应的全局承诺访问速率GCAR；

主控板在QoS表中记录该流量特征对应的GCAR以及各个业务板的本地承诺访问速率LCAR；

主控板将所述流量特征下发给各个业务板；

业务板接收主控板下发的流量特征，根据该流量特征对应的预设的本地承诺访问速率LCAR执行QoS CAR处理。

16.根据权利要求14所述的方法，其特征在于：其中LCAR一次上调或者一次降低的幅度为预定的速率步长UR。

17.根据权利要求14所述的方法，其特征在于：

所述业务板统计本板与某流量特征对应的TAR包括：统计本板下一个预定周期内所述流量特征对应的TAR；

所述预定趋势算法包括：

如果TAR大于LCAR且两者差值大于或等于第一速率阈值FRS，则确定变化趋势为上升趋势；

如果TAR不大于LCAR且两者差值大于或者等于第二速率阈值SRS，则确定变化趋势为下降趋势。

18.根据权利要求17所述的方法，其特征在于：所述SRS大于FRS。

19.根据权利要求18所述的方法，其特征在于：其中SRS大于或等于UR或为UR的N倍，N为大于1的自然数。

20.一种分布式网络设备的主控板，包括处理器、内存以及非易失性存储器，该分布式网络设备还包括一个或者多个业务板；其中所述非易失性存储器包括若干计算机可读指令，所述处理器运行该些计算机可读指令以执行如下处理过程：

接收到任意一个业务板针对某流量特征的本地承诺访问速率LCAR上调申请后，在预设的QoS表中查找与该流量特征对应的表项；

在确定查找到的对应表项中的全局承诺访问速率GCAR大于各个业务板的本地承诺访问速率LCAR总和后，通知业务板该申请被接受，并更新该对应表项中该业务板的LCAR；

接收到任意一个业务板针对该流量特征的降低LCAR通知后，在所述QoS表中查找对应的表项，并更新查找到的对应表项中的该业务板的LCAR。

21.根据权利要求20所述的主控板，其特征在于，所述处理过程还包括：

接收管理侧下发的流量特征以及对应的全局承诺访问速率GCAR；

在QoS表中记录该流量特征对应的GCAR以及各个业务板的本地承诺访问速率LCAR；

将所述流量特征下发给各个业务板。

22.根据权利要求21所述的主控板，其特征在于：还包括：

根据GCAR以及业务板数量确定各个业务板的初始LCAR，并将每个业务板的初始LCAR分别下发给各个业务板。

23.根据权利要求20所述的主控板，其特征在于：其中LCAR一次上调或者一次降低的幅度为预定的速率步长UR。

24.一种分布式网络设备的业务板，包括处理器、内存以及非易失性存储器，该分布式网络设备还包括一个或者多个业务板；其中所述非易失性存储器包括若干计算机可读指令，所述处理器运行该些计算机可读指令以执行如下处理过程：

统计本板与某流量特征对应的流量接收速率TAR；

根据预定趋势算法确定所述TAR相对于所述流量特征对应的本地承诺访问速率LCAR的变化趋势；

在确定所述变化趋势为上升趋势后，向主控板发送对应的LCAR上调申请，并在接收到主控板接受所述申请的通知后上调所述LCAR；

在确定所述变化趋势为下降趋势后，降低所述LCAR并通知主控板。

25.根据权利要求24所述的业务板，其特征在于：

所述统计本板与某流量特征对应的TAR包括：统计本板下一个预定周期内所述流量特征对应的TAR；

所述预定趋势算法包括：

如果TAR大于LCAR且两者差值大于或等于第一速率阈值FRS，则确定变化趋势为上升趋势；

如果TAR不大于LCAR且两者差值大于或者等于第二速率阈值SRS，则确定变化趋势为下降趋势。

26.根据权利要求25所述的业务板，其特征在于：

其中LCAR一次上调或者一次降低的幅度为预定的速率步长UR。

27.根据权利要求25所述的业务板，其特征在于：所述SRS大于FRS。

28.根据权利要求27所述的业务板，其特征在于：其中SRS大于或等于UR或为UR的N倍，N为大于1的自然数。

29.根据权利要求24所述的业务板，其特征在于：所述统计本板与某流量特征对应的TAR包括：

统计本板下一个第一预定周期内与某流量特征对应的第一TAR以及下一个第二预定周期内与该流量特征对应的第二TAR；

所述预定趋势算法包括：

如果第一TAR大于LCAR且两者差值大于或等于第一速率阈值FRS，则确定变化趋势为上升趋势；

如果第二TAR不大于LCAR且两者差值大于或者等于第二速率阈值SRS，则确定变化趋势为下降趋势。

30.根据权利要求29所述的业务板，其特征在于：所述第二预定周期大于所述第一预定周期。

31.根据权利要求24所述的业务板，其特征在于：其中LCAR的初始值是主控板下发的。

32.根据权利要求24所述的业务板，其特征在于：所述处理过程还包括：

接收主控板下发的流量特征，根据该流量特征对应的预设的本地承诺访问速率LCAR执行QoS CAR处理。