CN100414916C - 网络灾难时的优先级报文流量保证方法 - Google Patents
网络灾难时的优先级报文流量保证方法 Download PDFInfo
- Publication number
- CN100414916C CN100414916C CNB031563244A CN03156324A CN100414916C CN 100414916 C CN100414916 C CN 100414916C CN B031563244 A CNB031563244 A CN B031563244A CN 03156324 A CN03156324 A CN 03156324A CN 100414916 C CN100414916 C CN 100414916C
- Authority
- CN
- China
- Prior art keywords
- disaster
- priority
- message
- under
- bandwidth
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明涉及一种网络灾难时的优先级报文流量保证方法,在出现灾难时,保证超过网络容量的高优先级报文不被丢弃,实现整网高优先级流量保证。包括:报文入队列前,先判断灾难发生状态;在正常状态下,使用正常状态下为接口出端口的一套优先级队列配置的一套带宽参数,在配置的正常带宽参数下,报文按优先级高低入该套队列;在灾难状态下,使用灾难状态下为接口出端口的一套优先级队列配置的一套灾难带宽参数,在配置的灾难带宽参数下,报文按优先级高低入该套队列。可只有一套接口出端口优先级队列,分别使用所配置的正常带宽参数和灾难带宽参数;也可设置两套分别配置了正常带宽参数和灾难带宽参数的接口出端口优先级队列。
Description
技术领域
本发明涉及一种网络技术,在由通信设备组成的网络中,当发生严重故障-称之为网络灾难时,网络中优先级报文流量的保证技术,即一种网络带宽的预留技术。
背景技术
在由通信设备连接组成的网络中,当发生断路等故障时,因重新选择路径会引起网络中流量的变化,难免发生拥塞,严重时甚至造成优先级报文丢包。
下面结合弹性分组环网(RPR:RESILIENT PACKET RING)来说明这种优先级报文的丢包问题。
弹性分组环网技术是一种新兴的带有自愈功能的环网技术,由于它具有高效、安全、稳定等优点,从而得到了广泛应用。
RPR环是类似以太网的广播网络,和以往的以太网令牌环(Token Ring)相比,RPR环的效率比较高。主要体现在令牌环(Token Ring)是源删除,而RPR环是目的删除,即当一个单播报文在环上传送的时候,目的删除是报文到达目的地以后就从环上被删除,例如图1中AB的报文将在B处被删除,不会占用BCDA的带宽;源删除则需要将报文沿环传送到发送报文的源节点以后,才被删除,比如图1中AB的报文,需要经过ABCDA的过程,才能被删除。
RPR环的内环和外环都是单向数据流,向固定的方向传送数据。如图1中内环11和外环12,内环11中的单向数据流是逆时针方向的,外环12中的单向数据流是顺时针方向的。
RPR环的另外一个功能是发生故障时的自愈功能,即当RPR环上的某一个节点出现故障时,如图2中假定原来A C的流量走外环12(ADC),当D、C之间的光纤断路时,D节点会自动将流量环回(Wrap),将来自外环12的流量环回入内环11,即暂时由内环11将数据报文传送到C节点(DABC)。
环回(Wrap)以后,节点设备会根据新学习到的网络拓扑信息,进行重新选环(走内环还是外环),重新选环后,AC的流量将被修改为走内环11从ABC传送,如图2中箭头13所示;原来由D节点发送给C节点的流量,也变为经过内环11从DABC发送给C,如图2中箭头14所示。
在以上的故障处理中,流量从ADC变成ABC过程中,会和原来从B到C的流量叠加,如果叠加后的流量比较大,就会在B节点产生拥塞。由于一般的RPR环都是核心网或者骨干网,也即网络的利用率通常较高,上述故障处理过程会导致B点产生非常严重的拥塞情况,极端情况下,可能是RPR单环流量的2倍甚至更多。在环回倒换中,由于流量的变化,不可避免地会发生一些丢包,因为在重新选环以后(流量走内环以后),在很长时间之内网络可能都保持在这种状态下运行,一直等断掉的连接或者出现故障的节点被恢复时。如何在这么拥塞的情况下保证各种报文特别是高优先级报文不被丢弃,是需要认真对待的。
目前的保证方法是通过算法进行的,投入应用的有Cisco的公平算法技术。这个公平算法,在没有故障时也生效(没有故障时,一般拥塞也不严重)。还以上面的例子来说明。在RPR环没有故障时,如果A→D→C有流量(称之为Fac),同时D→C也有流量(称之为Fdc)。当两个流量之和大于环上传输的总带宽时,在节点D将产生拥塞。公平算法将暂时抑制节点D上环的流量,同时向节点A发送拥塞反压报文,告诉A节点链路拥塞,A节点收到该拥塞反压报文后将减小Fac流量,从而解决D节点上的拥塞问题,保证环上的畅通。
在上面处理拥塞、抑制节点D的流量中,将抑制低优先级流量,不抑制高优先级流量,以此来保证高优先级报文不会被丢弃。
上例中,当环上发生故障造成B节点拥塞时,同样启动公平算法,将暂时抑制节点B上环的流量,同时通过向节点A发送拥塞反压报文,减小Fac流量,从而解决B节点上的拥塞问题,保证环上的畅通。
因此公平算法在正常流量下使用,不失为一个好的算法。
但是在实际应用中,当发生环灾难情况,如D、C之间的光纤断路,且Fac(从A经过B发送给C的流量)和Fbc(从B发送给C的流量)都非常大(比如在2.5G的环上,A节点到C节点的流量有1G的组播报文+600M高优先级报文+2.4G低优先级报文,B节点到C节点的还有400M高优先级报文和1.6G低优先级报文,按照算法,应该丢弃低优先级报文2.4G+1.6G,保证高优先级报文600M+400M和1G的组播报文),同时环上还有大量多播报文(采用广播发送形式)流量时,在B节点到C节点之间出现严重拥塞。
这时使用公平算法,发现会出现高优先级报文和高优先级组播报文少量丢包的情况,经过分析,是由于对于高速的RPR环(如2.5G),节点上包含公平算法的芯片的缓冲区(Buff)不够大,不能吸收突发的大量拥塞造成的。
由于高优先级报文一般是比较重要的报文(比如语音流),高优先级组播报文一般是视频流。少量丢包可能会引起图像声音不清晰,因此在实际应用中是不允许发生高优先级报文或高优先级组播报文丢包的。
我们把在特别拥塞情况下,实际实现中无法保证高优先级报文完全不丢包的缺陷称为A缺陷。当然该缺陷可以通过增大节点上RPR芯片的Buff来解决(但是需要修改RPR芯片设计)。
另外,当RPR环上各种高优先级报文相加后的流量大于灾难状态下可以利用的带宽时,必然会出现高优先级报文丢包的情况,而且对于所有参与叠加的各高优先级报文流量,都可能出现丢包。
例如图3中,假定这个环是2.5G的RPR环。假设Fdc(D到C的流量)中包含1G的高优先级报文,Fac中包含1G的高优先级报文,Fbc中又包含1G的高优先级报文,这些流量,在环无灾难的情况下,Fdc走外环发送给C,Fbc走内环发送给C,不管Fac经B节点走内环,还是Fac经D节点走外环,都不超过2.5G,所以高优先级报文都不会被丢弃。
在D、C之间发生光纤断路的灾难状态下,D、A、B送给C的流量都走内环,这样B、C之间的流量将大于2.5G(和为3G),这时公平算法将会导致3个流量都可能丢包,这是用户不愿接收的结果。实际上,用户希望在这种状态下,通过减少某一个高优先级报文流量来实现整网高优先级报文不丢包,而不是全部都可能丢包。
我们把这种高优先级流量超过灾难情况下环的容量、所有高优先级报文都可能出现丢包的缺陷称为B缺陷。
本发明需要解决的就是在采用公平算法时所遇到的两种缺陷。在说明本发明技术方案之前还要先介绍以下预备知识。
在各个节点上环的接口上,目前各INTERNET服务提供商(ISP)都使用了差分服务(DiffServ,以下称DiffServ)来区分高低优先级队列。DiffServ使用IP头中8位TOS域中的6位(称为DSCP域),因而可以将流分成64类,目前标准已定义了6类:EF(Expedited Forwarding)、AF1~AF4(Assured Forwarding)和BE(Best Effort),其它暂时保留。其中EF类为最高优先级,AF1~AF4类为用户自己定义的优先级,BE类为最低优先级。
为了保证各个优先级报文的流量,在RPR各个节点的接口出口都定义了6个队列,分别对应上述6类流。其中EF队列和其它队列之间存在严格的高低优先级关系,只有EF队列发送完毕以后才能发送其它队列的流(采用一种优先级队列算法,其专业术语为PQ算法,PQ:Priority Queue)。用户为了保证优先级,对这六种队列分别配置一定的带宽或者调度的权值(Weight值)。通过使用调度算法对不同优先级队列的带宽进行保证性限制或者分配。
不同厂商使用不同的调度算法,包括低时延带宽保证算法(简称LLS算法,LLS:Low-latency sustainable bandwidth)、一般时延带宽保证算法(简称NLS算法,NLS:Normal-latency sustainable bandwidth)、加权公平队列算法(简称WFQ算法,WFQ:weighted fair queuing)、和峰值速率带宽限制算法(简称PBS算法,PBS:Peak bandwidth service)。LLS和NLS都是对队列的带宽进行保证的算法,不同的是:LLS算法保证的带宽有更好的时延。WFQ算法可以根据配置的权值分配带宽。PBS算法是限制最大带宽的算法,即超过配置带宽的流量都将被丢弃。
发明内容
本发明的目的是设计一种网络灾难时的优先级报文流量保证方法,通过给用户提供一种技术手段,解决如RPR环一类的网络,在出现灾难时,不管高优先级报文是否超过网络环容量,都可保证高优先级报文不被丢弃,实现整网的高优先级流量保证。
本发明通过一种简单有效的“灾难带宽预留技术”,即通过设计网络带宽的预留方案,对各种优先级流量使用预先配置好的带宽和算法进行限制,使RPR一类网络发生灾难时,保证高优先级报文不会被丢弃,以确保整网优先级报文的流量。
实现本发明目的的技术方案是这样的:一种网络灾难时的优先级报文流量保证方法,其特征在于包括以下处理步骤:
A.在网络的节点设备接口出端口上,报文入队列前,先判断当前的灾难发生状态;
B.在无灾难发生的正常状态下,使用正常状态下为接口出端口的一套优先级队列配置的一套带宽参数,在配置的正常带宽参数下,报文按流优先级高低入该套队列;
C.在有灾难发生的灾难状态下,使用灾难状态下为接口出端口的一套优先级队列配置的一套灾难带宽参数,在配置的灾难带宽参数下,报文按流优先级高低入该套队列。
可以只有一套接口出端口优先级队列,在正常状态下使用配置的正常带宽参数,在灾难状态下使用配置的灾难带宽参数;也可设置两套接口出端口优先级队列,在正常状态下使用一套配置了正常带宽参数的队列,在灾难状态下使用另一套配置了灾难带宽参数的队列。
在灾难状态下,还可在网络的节点设备接口入口端上使用和/或增加和/或变更报文流规则和对报文流的动作,用于改变和调整报文的优先级、带宽、转发的路径。
本发明在需要执行网络灾难带宽预留的节点接口上,通过配置灾难队列中高优先级队列的保证带宽和最大(峰值)带宽,来限制个别节点在灾难情况下上环的高优先级带宽,从而实现灾难情况下环上高优先级带宽不会超过物理带宽。
本发明方法给用户提供了一种手段,解决了在RPR环一类的网络出现灾难时,当高优先级报文不超过环容量但是特别拥塞的情况下,尽量丢弃低优先级报文,保证高优先级报文不被丢弃;当高优先级报文超过环容量时,允许通过用户预先配置好的带宽参数,对流量中的某个节点进行限制,从而实现整网的高优先级保证。
本发明方法的有益效果是解决了在RPR环一类网络发生灾难的状况下,由于使用公平算法带来的两个缺陷-A缺陷和B缺陷。
对于特别拥塞情况下不能保证高优先级报文完全不丢包的缺陷A,本发明方法可以通过对灾难队列低优先级报文配置峰值服务速率算法(PSR:PeakService Rate),通过限制低优先级流量的最大带宽进行解决,用户可以根据高优先级报文的总的可能的带宽(B1)和网络环上的物理带宽(B2),得出允许上环的低优先级的报文带宽(B3),一般可以采用B3稍微大于(B2-B1)的方法进行。因为公平算法在一定程度上还是起作用的,所以允许高优先级报文的总的可能的带宽(B1)可以大于物理带宽(B2),对于不同型号的设备,各部分报文所占带宽的比例需要根据实际试验的经验值来决定。LLS/NLS和PBS、WFQ算法可以一起使用,可以实现既保证一定带宽(使用LLS或者NLS),又限制其最大带宽(同时使用PBS)。有关的算法可参考相关的介绍文档,由于其使用方法已经超出了本发明涉及的技术范围,故不再详述。
对于灾难状态下,高优先级流量超过环容量时所有高优先级报文都可能出现丢包的缺陷B,本发明方法,可以通过配置灾难队列中高优先级的保证带宽和最大(峰值)带宽,来限制个别节点在灾难情况下上环的高优先级带宽,从而实现灾难情况下环上高优先级带宽不会超过物理带宽,保证最重要业务的传送。
本发明的技术在于增加了发现网络故障之后的操作,在本发明之前,一般故障发生时仅采用告警,而本发明方法则还主动采用对节点进行带宽限制等操作。
附图说明
图1是RPR环结构示意图;
图2是RPR环故障情况下,节点A到C和节点D到C的流量情况示意图;
图3是RPR环故障情况下,Fdc、Fac、Fbc流量情况示意图;
图4是在灾难状态下的队列切换流程示意图。
具体实施方式
本发明方法依据的最基本原则是:在环(网络)发生灾难(故障)时,对低优先级流量使用预先配置好的带宽和策略进行限制,从而保证高优先级流量的传送。
在环出现故障时,RPR自身的协议会很快发现环上的故障,并知道发生了环回(Wrap),开始重新选环。在重新选环以后,进入一种故障状态下的稳定状态,这时环上实际可以利用的带宽已经远远小于故障前的带宽,一般情况下,可利用的带宽将小于等于原带宽的1/2。但是这时,各个上环的RPR节点接口的出端口队列,实际还是按照故障前的配置来配置带宽保证等调度参数的,这也是造成环上拥塞严重的根本原因。
本发明方法中,在每个需要执行网络灾难带宽预留的节点接口上设置12个队列。其中6个是用户正常使用的队列(EF,AF1-AF4和BE),称之为正常队列。另外6个为灾难状态下使用的队列,称之为灾难队列。用户可以在灾难队列上配置自己的带宽参数。这些带宽参数可以根据规划的情况,在网络建立之初就进行配置。
RPR网络发生灾难时,通过RPR自身的协议可以很快得知该灾难,然后下发给业务平面(转发平面),该转发平面将改变报文所入的队列,即将报文入对应的灾难队列,这样,为灾难队列所配置的参数将发挥作用,以保证灾难状态下,业务带宽能按照用户的需求进行传送。
业务平面(转发平面)对入队列的修改,用伪码标识如下:
if(灾难发生==True)
报文入对应的灾难DiffServ队列
Else
报文入正常DiffServ队列
控制平面的修改为:
(1)如果RPR网络发生灾难,则设置业务平面的灾难发生标志位;
(2)增加灾难队列的分配机制和允许配置带宽机制。
上述转发平面是数据业务处理的平面,控制平面通过下达指令控制转发平面操作。
下面说明转发平面如何改变报文入队列。每个网络处理器中有很多队列,可以通过配置寄存器,将队列指定到某个端口。将队列指定到某个端口就是这个队列的报文将会从这个端口发送出去。现有每个接口有固定的6个队列,6个队列是顺序增加的,每个接口有一个队列的基址。比如接口1,假定第一个队列从129开始,那么基址就是128,第一个队列=基址+端口队列偏移。
使用本发明的方法时,可为每个接口分配12个队列,前6个队列配置的参数是用户配置的正常情况下的参数(比如保证带宽、最大带宽等等),另外6个队列平时是不用的,是灾难情况下的灾难队列,用户可以预先配置灾难情况下这些队列的参数(比如保证带宽、最大带宽等等)。
结合参见图4,在报文入队列前,需要判断灾难发生标志位(步骤41),当这个标志位为0时,表明灾难没有发生,报文就会入正常的队列(步骤43)。在灾难发生时,通过RPR自己的协议,可以很快学习到灾难发生,然后将这个标志位置1。当判断标志位为1时,报文入灾难队列,从而完成了队列的切换(步骤42),这样就可使用灾难情况下配置的参数。
上述过程用伪码标识如下:
控制平面:
if(灾难发生)
{设置转发平面灾难flag=1;}
else
{灾难Flag=0;}
if(灾难回复)
{设置转发平面灾难flag=0;}
数据平面:
if(灾难flag==0)
{ 报文入正常队列;}
Else
{ 报文入队列的号=报文入队列的号+6;
报文入队列(灾难队列)
}
控制平面修改之(1)在上述过程中的体现,就是在发现灾难以后,设置数据平面的对应标志位。
本发明方法,对可以预知的关键通信设备或者由通信设备组成的网络的灾难(故障),设置一套适合灾难(故障)的参数,在灾难发生时使用,来达到灾难情况下希望达到的结果;对于RPR这种特定的网络,通过设置灾难(故障)情况下的带宽参数,来保证灾难(故障)情况下,重要业务的传送,或者某些用户希望达到的特殊目的;对于通信设备或者网络灾难情况下,同一个优先级或者说同一种业务的报文,当其超过灾难情况下的实际传送能力时,可以通过预先设定的参数或者配置方案,重新对带宽、优先级等进行配置,达到保证更重要业务的目的;所配置的灾难情况下的参数,在正常情况下不使用,只在灾难发生时使用。
下面参考图3举例说明本发明的带宽预留技术。
正常情况下,A→C和D→C走外环,B→C走内环,假定目前只有B→C和A→C,D→C三个流量。EF队列是最高优先级数据队列,通常用于传送语音、图像等业务。对于本例组网,一个环允许的最大带宽是2.5G。
正常情况下,配置A节点RPR接口上队列的参数如表1所示:
队列 | 保证带宽 | 最大带宽 |
EF | 1000M | 1000M |
AF1 | 100M | |
AF2 | 100M |
表1
正常情况下,配置D节点RPR接口上队列的参数如表2所示:
队列 | 保证带宽 | 最大带宽 |
EF | 1000M | 1000M |
AF1 | 100M | |
AF2 | 100M |
表2
正常情况下,配置B节点RPR接口上队列的参数如表3所示:
队列 | 保证带宽 | 最大带宽 |
EF | 1000M | 1000M |
AF1 | 500M | 700M |
AF2 | 500M | 800M |
表3
正常情况下,A→C和D→C走外环时,环中的保证带宽流量为1000M+100M+100M+1000M+100M+100M=2400M<2.5G,可以传送。B→C走内环时,环中的保证带宽流量为:1000+500+500=2000M<2.5G,也可以传送。
灾难情况下,配置A节点RPR接口上队列的参数如表4所示:
队列 | 保证带宽 | 最大带宽 |
EF | 500M | 500M |
AF1 | 0 | |
AF2 | 0 |
表4
灾难情况下,配置D节点RPR接口上队列的参数如表5所示:
队列 | 保证带宽 | 最大带宽 |
EF | 1000M | 1000M |
AF1 | 0 | |
AF2 | 0 |
表5
灾难情况下,配置B节点RPR接口上队列的参数如表6所示:
队列 | 保证带宽 | 最大带宽 |
EF | 1000M | 1000M |
AF1 | 0 | |
AF2 | 0 |
表6
如果不使用本发明的方法,在发生D,C之间断路的故障状态下,以上流量A→C,D→C,和B→C将都走内环,所以总EF流量=1000+1000+1000=3000M>2.5G。虽然采用公平算法可以使AF流被丢弃,但是当EF流已经大于环的容量时,将公平的丢弃来自A,B,D节点的EF流量,这样三个节点的流量都会有丢包。
采用本发明的方法后,如果认为A节点不重要(指上环流量),可以对A进行限制,容忍丢弃一部分A上的EF流量(如表4所示),此时总EF流量=500+1000+1000=2500M=2.5G,这样使总的EF流仍然在环带宽之内,以保证B,D流量正常。
在上述实施方案中,是使用两套不同的队列来达到本发明带宽预留目的的,实际实现中,还可以考虑采用其它方案,包括:
可以只使用一套队列,但是使用两套(或两套以上)参数。平时正常情况下使用一套正常带宽参数,在网络灾难发生时,使用预先配置的灾难带宽和调度算法参数,也可以达到同样效果。但是软件设计要略微复杂一些。
其具体实现是:预先为队列配置好灾难情况下的队列参数,队列分配和正常情况下一样,还是每个接口设6个队列。但是在控制平面,为每个端口保留两套参数,一套是用户配置的正常情况下的参数,另一套是用户配置的用于灾难情况下的参数。当灾难发生时,同样通过RPR协议得知灾难发生,然后控制平面就会将灾难情况下的队列参数(保证带宽,峰值带宽等)配置到各个队列。这样每个队列使用的参数就是灾难情况下的参数了。在回复正常以后,会自动配置正常情况下的参数,这样就又回复了正常情况下的参数配置。
用伪码标识表示如下:
控制平面:
If(灾难发生)
{下发灾难带宽参数到数据平面}
if(灾难回复)
{下发正常带宽参数到数据平面}
数据平面:不用修改
控制平面修改之(2)在上述过程中的体现,就是在发现灾难以后,配置数据平面的队列参数。
本发明方法在实施时还可以进行扩展,如对灾难(故障)的级别进行定义,对不同的灾难(故障)级别使用不同的参数或者不同的灾难配置方案,或者使用不同的队列(如果队列足够多的话)。例如:RPR环上一个节点故障时采用配置方案1;两个节点故障时采用配置方案2等等。对于通信设备或者网络,有多种级别灾难(故障)的情况,可以设置多套参数或者方案;根据灾难(故障)实际发生的级别,自动使用对应的参数或者方案。对于故障级别和故障状态的感知,可以由通信设备通过协议、信号等手段自动感知,也可以由人工直接设置。
更进一步地,在灾难发生时,还可根据需要,在网络的节点设备接口入口端上使用和/或增加和/或变更相对于正常情况而言的部分或全部报文流规则以及对报文流的动作,用于改变和调整报文的优先级、带宽甚至转发的路径。这些报文流规则是由报文本身具有的特征以及转发中的特征组成的供区分数据流的各种要素以及它们的任意组合(包括掩码方式和范围方式等),包括报文的源接口、目的接口、源物理(MAC)地址、报文的目的物理(MAC)地址、IP报文源地址、IP报文目的地址、网络协议类型、传输控制协议(TCP)源端口、传输控制协议(TCP)目的端口、用户数据报协议(UDP)源端口、用户数据报协议(UDP)目的端口、是否是分片报文和是否是传输控制协议(TCP)同步报文等。对报文流的动作,包括过滤(丢弃)报文,对报文重新登记优先级(Remark)、对报文进行访问速率限制(CAR:Committed Access Rate)、实施策略路由和重定向等可以用于通信设备数据流的一切动作和它们的组合。
例如在上述举例配置灾难情况下A节点RPR接口上队列的参数时,还可对A上的流量进行更细致的划分。比如A节点上环的流量是来自多个端口的,有的端口是连接比较重要的客户,有的端口是连接不太重要的客户。在对A上EF队列进行限制的同时,可以通过识别流量的源端口,降低EF报文的优先级,比如将不重要端口的EF流降低其优先级为AF1流,这样,在A节点上也可以实现对重要客户的高优先级流的保证。
由RPR环网推广开来,对于其它通信设备节点及其组成的网络故障,也可以采用本发明的方法。
本发明方法在实施时还可为用户提供更多的选择,使用户对网络灾难状态下的带宽实现可控。对于保证网络上高优先级业务的传输,提高网络的可靠性有重要意义。
本发明方法还可以推广到其它类似问题的解决中,采用区分故障状态和正常状态的方法,预先对可能出现的灾难(故障)状态进行预防和预先规划,从而主动、有效的解决问题。
实施时,还可以通过访问速率限制(CAR:Committed Access Rate)等手段或者其它带宽保证、带宽限制算法来实现本发明中的带宽限制,不一定是上面描述的LLS、NLS等算法。
Claims (12)
1. 一种网络灾难时的优先级报文流量保证方法,其特征在于包括以下处理步骤:
A.在网络的节点设备接口出端口上,报文入队列前,先判断当前的灾难发生状态;
B.在无灾难发生的正常状态下,使用正常状态下为接口出端口的一套优先级队列配置的一套带宽参数,在配置的正常带宽参数下,报文按流优先级高低入该套队列;
C.在有灾难发生的灾难状态下,使用灾难状态下为接口出端口的一套优先级队列配置的一套灾难带宽参数,在配置的灾难带宽参数下,报文按流优先级高低入该套队列。
2. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤A中,判断当前的灾难发生状态是判断灾难发生标志位的状态,在网络协议学习到灾难发生时对灾难发生标志位置位,在网络协议学习到灾难回复时对灾难发生标志位复位。
3. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤B中接口出端口的一套优先级队列是正常状态下使用的一套队列;所述步骤C中接口出端口的一套优先级队列,是增设的一套灾难优先级队列,该套灾难优先级队列使用所配置的一套灾难带宽参数。
4. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤A中,还包括判断当前的灾难发生级别;所述步骤B中接口出端口的一套优先级队列是正常状态下使用的队列;所述步骤C中接口出端口的一套优先级队列,是从增设的多套灾难优先级队列中按灾难发生级别选择的一套队列,每一套灾难优先级队列配置一套灾难带宽参数,一种灾难发生级别与一套灾难优先级队列对应。
5. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤B与所述步骤C中,接口出端口的一套优先级队列是同一套队列,在步骤B的正常状态下使用配置的正常带宽参数,和在步骤C的灾难状态下使用配置的灾难带宽参数。
6. 根据权利要求5所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述的灾难带宽参数有一套以上,分别与灾难实际发生的级别对应。
7. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述的灾难带宽参数包括各种优先级队列下的保证带宽和最大带宽及带宽保证的调度算法。
8. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述的灾难带宽参数预先配置在网络的关键通信节点设备上,或者需要执行网络灾难带宽预留的节点接口上。
9. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤C中进一步包括,对所述接口出端口的一套优先级队列,将其最高优先级队列上的报文降低为低优先级队列上的报文。
10. 根据权利要求1所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述步骤C中还包括,在网络的节点设备接口入口端上使用和/或增加和/或变更相对于正常情况而言的报文流规则和对报文流的动作,用于改变和调整报文的优先级、带宽、转发的路径。
11. 根据权利要求10所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述的报文流规则是由报文本身具有的特征以及转发中的特征组成的供区分数据流的各种要素以及它们的任意组合。
12. 根据权利要求10所述的网络灾难时的优先级报文流量保证方法,其特征在于:所述的对报文流的动作,包括过滤报文,对报文重新登记优先级、对报文进行访问速率限制、实施策略路由和重定向。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB031563244A CN100414916C (zh) | 2003-09-03 | 2003-09-03 | 网络灾难时的优先级报文流量保证方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CNB031563244A CN100414916C (zh) | 2003-09-03 | 2003-09-03 | 网络灾难时的优先级报文流量保证方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1592267A CN1592267A (zh) | 2005-03-09 |
CN100414916C true CN100414916C (zh) | 2008-08-27 |
Family
ID=34598379
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CNB031563244A Expired - Fee Related CN100414916C (zh) | 2003-09-03 | 2003-09-03 | 网络灾难时的优先级报文流量保证方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN100414916C (zh) |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1867097B1 (en) * | 2005-03-10 | 2016-11-02 | Telecom Italia S.p.A. | Disaster recovery architecture |
EP2262181A1 (en) * | 2008-03-31 | 2010-12-15 | Panasonic Corporation | Communication terminal device and communication control method |
CN102368736B (zh) * | 2011-11-10 | 2014-12-10 | 华为技术有限公司 | 一种报文发送方法和设备 |
CN113906720B (zh) * | 2019-06-12 | 2024-05-10 | 华为技术有限公司 | 流量调度方法、设备及存储介质 |
CN112087257B (zh) * | 2019-06-13 | 2022-04-12 | 华为技术有限公司 | 一种光网络的故障保护方法、设备和系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000074318A1 (en) * | 1999-06-02 | 2000-12-07 | Marconi Communications, Inc. | Transmitter-based path protection switching in a ring network |
US20020027928A1 (en) * | 2000-08-24 | 2002-03-07 | Fang Rong C. | Apparatus and method for facilitating data packet transportation |
CN1412977A (zh) * | 2001-10-10 | 2003-04-23 | 阿尔卡塔尔公司 | 在rpr网中传播故障信息的方法及相应rpr数据包 |
CN1437356A (zh) * | 2002-02-06 | 2003-08-20 | 日本电气株式会社 | 在一个通信网络中建立不同的故障恢复类型的路径的方法 |
-
2003
- 2003-09-03 CN CNB031563244A patent/CN100414916C/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2000074318A1 (en) * | 1999-06-02 | 2000-12-07 | Marconi Communications, Inc. | Transmitter-based path protection switching in a ring network |
US20020027928A1 (en) * | 2000-08-24 | 2002-03-07 | Fang Rong C. | Apparatus and method for facilitating data packet transportation |
CN1412977A (zh) * | 2001-10-10 | 2003-04-23 | 阿尔卡塔尔公司 | 在rpr网中传播故障信息的方法及相应rpr数据包 |
CN1437356A (zh) * | 2002-02-06 | 2003-08-20 | 日本电气株式会社 | 在一个通信网络中建立不同的故障恢复类型的路径的方法 |
Also Published As
Publication number | Publication date |
---|---|
CN1592267A (zh) | 2005-03-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7327675B1 (en) | Fairness of capacity allocation for an MPLS-based VPN | |
CN100562006C (zh) | 路由系统中差异排队的系统和方法 | |
CN101523845B (zh) | 因为建立呼叫时性能下降而调整传输路径中编解码器速度的系统和方法 | |
US6859438B2 (en) | Policy based quality of service | |
US8320381B2 (en) | Application-aware policy enforcement | |
US8320245B2 (en) | Policy enforcement points | |
CN101406023B (zh) | 实现多协议标签交换网络差分业务流量工程的方法和系统 | |
US7751330B2 (en) | Method and apparatus for dynamically managing hierarchical flows | |
JP2001358772A (ja) | ランダム早期降格昇格マーカ | |
CN101102275B (zh) | 在以太网交换芯片上实现多级调度的方法 | |
CN106341346A (zh) | 基于SDN的数据中心网络中一种保障QoS的路由算法 | |
US8374082B2 (en) | Advanced bandwidth management | |
JP2004260832A (ja) | Ipアクセスネットワークにおいて保証サービス品質を伴うサービスを提供する方法 | |
KR20050086537A (ko) | 루터에서 패킷에 대한 논리 링크를 선택하는 방법 | |
CN101056274B (zh) | 一种分时流量管理方法及装置 | |
JP2007312159A (ja) | Ip通信制御システム及び制御方法並びに制御プログラム | |
CN100414916C (zh) | 网络灾难时的优先级报文流量保证方法 | |
CA2398009C (en) | Method and apparatus for access control for a communications network | |
JP2006345173A (ja) | ルータ制御装置、ルータ、ip−vpnシステム、及び、ルータ制御方法 | |
TW200303670A (en) | Inverse multiplexing of managed traffic flows over a multi-star network | |
CN101127705B (zh) | 实现网络传输服务质量的方法 | |
CN101141324B (zh) | 在以太网监控通道中实现传送信息区别处理的方法 | |
CN100490421C (zh) | Mpls环网中实现流量公平传送的方法 | |
CN100394736C (zh) | 利用逻辑媒体通道提高多媒体通信可靠性的方法 | |
Rovcanin et al. | Data traffic differentiation and qos on the train, in fast parameter varying, heterogeneous wireless networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20080827 Termination date: 20150903 |
|
EXPY | Termination of patent right or utility model |