MLPPP 组带宽容量的处理方法和装置 【技术领域】
本 发 明 涉 及 通 信 领 域，尤 其 涉 及 一 种 多 链 路 点 对 点 协 议 (Multilink-Point-to-Point Protocol， 简称为 MLPPP) 组带宽容量的处理方法和装置。背景技术
链路捆绑将多个封装相同链路层协议的接口捆绑到一起， 形成一条逻辑上的数据 链路。链路捆绑的作用有 ： (1) 流量负载分担 ： 出 / 入流量可以在多个成员接口之间分担 ； (2) 增加带宽 ： 链路捆绑接口的带宽是各可用成员接口带宽的总和 ； (3) 提高连接可靠性 ： 当某个成员接口出现故障时， 流量会自动切换到其他可用的成员接口上， 从而提高整个捆 绑链路的连接可靠性。
多链路点对点协议 (Multilink-Point-to-Point Protocol， 简称为 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 模块， 即， 与 正常流程一样配置 MLPPP 组 ； 然后， 根据用户的最小带宽需求在 MLPPP 最小激活链路数配置 模块中配置 MLPPP 组最小激活链路数 ； 再者， PPP 模块将 PPP 链路状态 (up 或 down) 变化实 时告知激活链路数比较模块， 激活链路数比较模块根据 PPP 模块中的 PPP 链路状态将当前 处于 up 状态的链路数与配置的最小激活链路数进行比较， 并根据比较结果进行相应通告 和处理。具体地， 如果当前处于 up 状态的链路数小于最小激活链路数 ( 即， MLPPP 组的可 用带宽不满足用户的要求 )， 则将 MLPPP 组停止工作 ( 即， 将 MLPPP 组的状态置为 down)， 同 时给出告警信息通告用户 ； 如果当前处于 up 状态的链路数大于最小激活链路数 ( 即， MLPPP 组的可用带宽满足用户的带宽要求 )， 则将处于 down 状态的 MLPPP 组置为 up， 后续按正常 流程处理。
综上所述， 本发明实施例给用户提供了一个配置最小激活链路数的人机接口， 使 得用户可以将期望的最小保证带宽值告知 MLPPP 组， 防止了由于 PPP 链路故障导致 MLPPP 组的带宽容量不满足带宽要求而造成 PPP 链路拥塞， 增加了系统的处理能力， 提高了用户 体验。
显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通用 的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装置所组成 的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而， 可以将它们存储 在存储装置中由计算装置来执行， 并且在某些情况下， 可以以不同于此处的顺序执行所示 出或描述的步骤， 或者将它们分别制作成各个集成电路模块， 或者将它们中的多个模块或 步骤制作成单个集成电路模块来实现。 这样， 本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的技 术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所作的任何修 改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。