專利名稱：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日
發明者劉微 申請人:中興通訊股份有限公司