专利名称：Mlppp组带宽容量的处理方法和装置的制作方法
技术领域：
本发明涉及通信领域，尤其涉及一种多链路点对点协议 (Multilink-Point-to-Point Protocol，简称为MLPPP)组带宽容量的处理方法和装置。
背景技术：
链路捆绑将多个封装相同链路层协议的接口捆绑到一起，形成一条逻辑上的数据 链路。链路捆绑的作用有(1)流量负载分担出/入流量可以在多个成员接口之间分担；增加带宽链路捆绑接口的带宽是各可用成员接口带宽的总和；(3)提高连接可靠性 当某个成员接口出现故障时，流量会自动切换到其他可用的成员接口上，从而提高整个捆 绑链路的连接可靠性。多链路点对点协议(Multilink-Point-to-PointProtocol，简称为 MLPPP)就是 这样一种链路捆绑技术，即，将多条点对点协议(Pointto Point Protocol，简称为PPP)链 路绑定到一起，用于弥补PPP协议一次只能处理一个实际链接的局限。发明人发现在上述的相关技术中，用户不知道MLPPP组当前有多少条协商好的 PPP链路、以及MLPPP组能够承载业务流量的最大带宽，所以，MLPPP组当前所能承载业务 流量的带宽可能会低于用户需要的最小带宽，而用户却无法得知该情况。例如，用户要求的 最小带宽为8M，MLPPP组当前绑定了 4条2M的PPP链路，一旦某条PPP链路通讯故障，则 导致该条PPP链路不可用，此时，MLPPP组可用带宽只有6M(小于最小带宽8M)，可见，此时 MLPPP组所能承载的带宽流量小于用户所要求的最小带宽，但是，由于用户无法得知该带宽 不足的情况，所以，没有相应的处理机制，可能会影响到用户数据的传输性能。
发明内容
本发明的主要目的在于提供一种MLPPP组带宽容量的处理方案，以至少解决上述 的相关技术中由于用户不知道MLPPP组能够承载业务流量的最大带宽而影响用户数据的 传输性能的问题。为了实现上述目的，根据本发明的一个方面，提供了一种多链路点对点协议MLPPP 组带宽容量的处理方法。根据本发明的MLPPP组带宽容量的处理方法包括以下步骤统计MLPPP组绑定的 处于开启状态的点对点协议PPP链路的个数；判断处于开启状态的PPP链路的个数是否小 于阈值；以及在处于开启状态的PPP链路的个数小于阈值的情况下，提示MLPPP组当前的带 宽容量已不能满足带宽需求。进一步地，阈值为预先配置的与带宽需求对应的最小激活链路的个数。进一步地，统计MLPPP组绑定的处于开启状态的PPP链路的个数包括检测MLPPP 组绑定的所有PPP链路的状态；统计状态为开启的PPP链路的个数。进一步地，MLPPP组的状态包括开启和关闭，当MLPPP组处于开启状态时，MLPPP组 能够承载业务报文；当MLPPP组处于关闭状态时，MLPPP组停止工作，不能够承载业务报文。
进一步地，提示MLPPP组当前的带宽容量已不能满足带宽需求包括置MLPPP组的状态为关闭，并上报对应的告警信息。进一步地，置MLPPP组的状态为关闭，并上报对应的告警信息之后，还包括在处 于开启状态的PPP链路的个数大于或者等于阈值的情况下，置MLPPP组的状态为开启。为了实现上述目的，根据本发明的另一方面，还提供了一种多链路点对点协议 MLPPP组带宽容量的处理装置。根据本发明的MLPPP组带宽容量的处理装置，该装置包括统计模块，用于统计 MLPPP组绑定的处于开启状态的点对点协议PPP链路的个数；判断模块，用于判断处于开启 状态的PPP链路的个数是否小于阈值；以及提示模块，用于在处于开启状态的PPP链路的个 数小于阈值的情况下，提示MLPPP组当前的带宽容量已不能满足带宽需求。进一步地，统计模块包括检测模块，用于检测MLPPP组绑定的所有PPP链路的状 态。进一步地，提示模块包括设置模块，用于设置MLPPP组的状态为关闭，其中，处于 关闭状态的MLPPP组停止工作，不能够承载业务报文；上报模块，用于上报与MLPPP组的关 闭状态对应的告警信息。进一步地，设置模块还用于在处于开启状态的PPP链路的个数大于或者等于阈值 的情况下，设置MLPPP组的状态为开启，其中，处于开启状态的MLPPP组能够承载业务报文。通过本发明，采用设置MLPPP最小激活链路数(阈值)的方式，解决了相关技术 中由于用户不知道MLPPP组能够承载业务流量的最大带宽而影响用户数据的传输性能的 问题，避免了 MLPPP组在PPP链路故障时由于带宽不足而造成的链路拥塞，保障了用户对 MLPPP组的带宽要求，增加了系统的处理能力，提高了用户体验。
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发 明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中图1是根据本发明实施例的MLPPP组带宽容量的处理方法的流程图；图2是根据本发明实施例的配置最小激活链路数的处理流程图；图3是根据本发明实施例的PPP链路状态由down变为up时的处理流程图；图4是根据本发明实施例的PPP链路状态由up变为down时的处理流程图；图5是根据本发明实施例的MLPPP组带宽容量的处理装置的结构框图；图6是根据本发明优选实施例的MLPPP组带宽容量的处理装置的结构框图。
具体实施例方式下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的 情况下，本申请中的实施例及实施例中的特征可以相互组合。图1是根据本发明实施例的MLPPP组带宽容量的处理方法的流程图，如图1所示， 该方法包括以下步骤步骤S102，统计MLPPP组绑定的处于开启状态的PPP链路的个数；步骤S104，判断处于开启状态的PPP链路的个数是否小于阈值；以及
步骤S106，在处于开启状态的PPP链路的个数小于阈值的情况下，提示MLPPP组当 前的带宽容量已不能满足带宽需求。
通过本发明实施例，采用设置阈值的方式，解决了相关技术中由于用户不知道 MLPPP组能够承载业务流量的最大带宽而影响用户数据的传输性能的问题，避免了 MLPPP 组在PPP链路故障时由于带宽不足而造成的链路拥塞，保障了用户对MLPPP组的带宽要求， 增加了系统的处理能力。优选地，上述阈值可以为预先配置的与带宽需求对应的最小激活链路的个数。该 方法实现简单，可操作性强。优选地，在步骤S102中，可以检测MLPPP组绑定的所有PPP链路的状态；统计状态 为开启的PPP链路的个数。该方法有利用对MLPPP组中处于开启状态的PPP链路的个数进 行统计，提高了系统的准确性。优选地，MLPPP组的状态可以包括开启(up)和关闭(down)，当MLPPP组处于开启 状态时，MLPPP组能够承载业务报文，实现MLPPP协议要求的分片重组以及负载分担等功 能；当MLPPP组处于关闭状态时，MLPPP组停止工作，不能够承载业务报文，无法实现MLPPP 协议要求的分片重组以及负载分担等功能，但此时PPP链路上的PPP协议报文可以正常收 发。定义MLPPP组的开启和关闭状态可以对属于MLPPP组的所有PPP链路进行统一的操作， 增加了系统的灵活性。优选地，在步骤S106中，在处于开启状态的PPP链路的个数小于阈值的情况下，可 以置MLPPP组的状态为关闭，并上报对应的告警信息。通过该方法可以通知用户MLPPP组 的带宽容量状态，使得在MLPPP组的带宽容量小于用户的带宽需求的情况下，PPP链路停止 工作，并对该情况发出告警信息以提醒用户做相应的处理，提高了用户体验。优选地，在步骤S106之后，在处于开启状态的PPP链路的个数大于或者等于阈值 的情况下，可以置MLPPP组的状态为开启。本优选实施例可以在MLPPP组的带宽重新满足用户的带宽需求时，恢复对MLPPP 组中PPP链路的保护操作，使得系统可以及时更新MLPPP组承载业务流量的状态，从而提高 了系统的利用率。图2是根据本发明实施例的配置最小激活链路数的处理流程图，如图2所示，该方 法包括以下步骤步骤S202，用户根据实际需求配置MLPPP组的最小激活链路数。步骤S204，检测MLPPP组中PPP链路的状态，统计当前处于up状态的PPP链路数。步骤S206，将当前处于up状态的PPP链路数与配置的最小激活链路数进行比较， 即，判断当前处于up状态的PPP链路数是否小于配置的最小激活链路数。若小于最小激活 链路数，则进入步骤S208 ；否则进入步骤S210。步骤S208，将MLPPP组down掉(停止工作，不承载业务报文)，并上报告警。此时， MLPPP组无法保证用户要求的最小带宽。步骤S210，MLPPP正常的处理流程，符合RFC1661和RFC1990。图3是根据本发明实施例的PPP链路状态由down变为up时的处理流程图，如图 3所示，该方法包括以下步骤步骤S302，检测MLPPP组中PPP链路的状态，统计当前处于up状态的PPP链路数。当MLPPP组中存在有PPP链路状态由down变为up的情况时，进入步骤S304。步骤S304，将当前处于up状态的PPP链路数与配置的最小激活链路数进行比较，即，判断当前处于up状态的PPP链路数是否小于配置的最小激活链路数。若小于最小激 活链路数，则说明收到PPP链路up通知之前，MLPPP组处于down状态，所以不需要再变化 MLPPP组状态，进入步骤S306 ；否则进入步骤S308。步骤S306，保持现有状态不作任何处理。步骤S308，判断当前MLPPP组是否处于up状态。若是，则不需要再变化MLPPP组 状态，保持现有状态不作任何处理；若不是转步骤S310。步骤S310，将MLPPP组的状态置为up，使其处于工作状态，并上报告警消失。图4是根据本发明实施例的PPP链路状态由up变为down时的处理流程图，如图 4所示，该方法包括以下步骤步骤S402，检测MLPPP组中PPP链路的状态，统计当前处于up状态的PPP链路数。 当MLPPP组中存在有PPP链路状态由up变为down的情况时，进入步骤S304。步骤S404，将当前处于up状态的PPP链路数与配置的最小激活链路数进行比较， 即，判断当前处于up状态的PPP链路数是否小于配置的最小激活链路数。若小于最小激活 链路数，则进入步骤S408 ；否则说明此PPP链路down不会影响MLPPP组的状态变化，进入 步骤S406。步骤S406，保持现有状态不作任何处理。步骤S408，判断当前MLPPP组是否处于up状态。若不是，则不需要再变化MLPPP 组状态，保持现有状态不作任何处理；若是进入步骤S410。步骤S410，将MLPPP组的状态置为down，使其停止工作，并上报告警。可见，本发明实施例是将当前处于up状态的PPP链路数与配置的最小激活链路数 (即，阈值)比较，并根据比较结果进行相应处理。当MLPPP组的带宽容量满足带宽要求时， 走正常流程；当MLPPP组的带宽容量不满足带宽要求时，采取保护操作，将MLPP组down掉， 并上报告警。另外，当MLPPP组的带宽容量重新满足带宽要求后，需要恢复保护操作前的正 常流程。图5是根据本发明实施例的MLPPP组带宽容量的处理装置的结构框图，如图5所 示，该装置包括统计模块52，用于统计MLPPP组绑定的处于开启状态的PPP链路的个数； 判断模块54，用于判断处于开启状态的PPP链路的个数是否小于阈值；以及提示模块56，用 于在处于开启状态的PPP链路的个数小于阈值的情况下，提示MLPPP组当前的带宽容量已 不能满足带宽需求。通过本发明实施例，采用设置阈值的方式，解决了相关技术中由于用户不知道 MLPPP组能够承载业务流量的最大带宽而影响用户数据的传输性能的问题，避免了 MLPPP 组在PPP链路故障时由于带宽不足而造成的链路拥塞，保障了用户对MLPPP组的带宽要求， 增加了系统的处理能力。图6是根据本发明优选实施例的MLPPP组带宽容量的处理装置的结构框图，如图 6所示，统计模块52包括检测模块522，用于检测MLPPP组绑定的所有PPP链路的状态。优选地，提示模块56包括设置模块562，用于设置MLPPP组的状态为关闭，其中， 处于关闭状态的MLPPP组停止工作，不能够承载业务报文；上报模块564，用于上报与MLPPP组的关闭状态对应的告警信息。优选地，设置模块562还用于在处于开启状态的PPP链路的个数大于或者等于阈 值的情况下，设置MLPPP组的状态为开启，其中，处于开启状态的MLPPP组能够承载业务报文。上述实施例提供了一种MLPPP组保证用户期望带宽的方法，以及在MLPPP组无法保证带宽要求的情况下的相应通告处理。通过检测绑定的各PPP链路状态，判断状态UP (状 态up符合RFC1661)的PPP链路数是不是达到了用户配置的阀值，若达到了该阈值，则按照 MLPPP协议正常往下处理，否则要进行相应的通告和处理机制。本发明还提供了另一优选实施例的MLPPP组带宽容量的处理装置，该装置可以包 括PPP模块、MLPPP模块、MLPPP最小激活链路数配置模块、激活链路数比较模块和通告处 理模块。其中，基于RFC1661的PPP模块和基于RFC1990的MLPPP模块用于实现PPP链路 的协商维护以及MLPPP基本功能。在具体实施过程中，可以包括以下步骤首先，使能PPP模块和MLPPP模块，S卩，与 正常流程一样配置MLPPP组；然后，根据用户的最小带宽需求在MLPPP最小激活链路数配置 模块中配置MLPPP组最小激活链路数；再者，PPP模块将PPP链路状态(up或down)变化实 时告知激活链路数比较模块，激活链路数比较模块根据PPP模块中的PPP链路状态将当前 处于up状态的链路数与配置的最小激活链路数进行比较，并根据比较结果进行相应通告 和处理。具体地，如果当前处于up状态的链路数小于最小激活链路数(即，MLPPP组的可 用带宽不满足用户的要求)，则将MLPPP组停止工作(S卩，将MLPPP组的状态置为down)，同 时给出告警信息通告用户；如果当前处于up状态的链路数大于最小激活链路数(S卩，MLPPP 组的可用带宽满足用户的带宽要求)，则将处于down状态的MLPPP组置为up，后续按正常 流程处理。综上所述，本发明实施例给用户提供了一个配置最小激活链路数的人机接口，使 得用户可以将期望的最小保证带宽值告知MLPPP组，防止了由于PPP链路故障导致MLPPP 组的带宽容量不满足带宽要求而造成PPP链路拥塞，增加了系统的处理能力，提高了用户 体验。显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用 的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成 的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储 在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示 出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或 步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技 术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修 改、等同替换、改进等，均应包含在本发明的保护范围之内。
权利要求
一种多链路点对点协议MLPPP组带宽容量的处理方法，其特征在于，包括以下步骤统计MLPPP组绑定的处于开启状态的点对点协议PPP链路的个数；判断所述处于开启状态的PPP链路的个数是否小于阈值；以及在所述处于开启状态的PPP链路的个数小于阈值的情况下，提示所述MLPPP组当前的带宽容量已不能满足所述带宽需求。
2.根据权利要求1所述的方法，其特征在于，所述阈值为预先配置的与带宽需求对应 的最小激活链路的个数。
3.根据权利要求2所述的方法，其特征在于，统计所述MLPPP组绑定的处于开启状态的 所述PPP链路的个数包括检测所述MLPPP组绑定的所有PPP链路的状态； 统计状态为开启的所述PPP链路的个数。
4.根据权利要求1所述的方法，其特征在于，所述MLPPP组的状态包括开启和关闭，当 所述MLPPP组处于开启状态时，所述MLPPP组能够承载业务报文；当所述MLPPP组处于关闭 状态时，所述MLPPP组停止工作，不能够承载业务报文。
5.根据权利要求4所述的方法，其特征在于，提示所述MLPPP组当前的带宽容量已不能 满足所述带宽需求包括置所述MLPPP组的状态为关闭，并上报对应的告警信息。
6.根据权利要求5所述的方法，其特征在于，置所述MLPPP组的状态为关闭，并上报对 应的告警信息之后，还包括在所述处于开启状态的PPP链路的个数大于或者等于所述阈 值的情况下，置所述MLPPP组的状态为开启。
7.一种多链路点对点协议MLPPP组带宽容量的处理装置，其特征在于，包括 统计模块，用于统计MLPPP组绑定的处于开启状态的点对点协议PPP链路的个数； 判断模块，用于判断所述处于开启状态的PPP链路的个数是否小于阈值；以及提示模块，用于在所述处于开启状态的PPP链路的个数小于阈值的情况下，提示所述 MLPPP组当前的带宽容量已不能满足所述带宽需求。
8.根据权利要求7所述的装置，其特征在于，所述统计模块包括 检测模块，用于检测所述MLPPP组绑定的所有PPP链路的状态。
9.根据权利要求8所述的装置，其特征在于，所述提示模块包括设置模块，用于设置所述MLPPP组的状态为关闭，其中，处于关闭状态的所述MLPPP组 停止工作，不能够承载业务报文；上报模块，用于上报与所述MLPPP组的关闭状态对应的告警信息。
10.根据权利要求9所述的装置，其特征在于，所述设置模块还用于在所述处于开启状 态的PPP链路的个数大于或者等于所述阈值的情况下，设置所述MLPPP组的状态为开启，其 中，处于开启状态的所述MLPPP组能够承载业务报文。
全文摘要
本发明公开了一种多链路点对点协议MLPPP组带宽容量的处理方法和装置，该方法包括以下步骤统计MLPPP组绑定的处于开启状态的点对点协议PPP链路的个数；判断处于开启状态的PPP链路的个数是否小于阈值；以及在处于开启状态的PPP链路的个数小于阈值的情况下，提示MLPPP组当前的带宽容量已不能满足带宽需求。通过本发明增加了系统的处理能力，提高了用户体验。
文档编号H04L29/08GK101854396SQ20101019157
公开日2010年10月6日 申请日期2010年5月31日 优先权日2010年5月31日
发明者刘微 申请人:中兴通讯股份有限公司