(57)【要約】  本発明の実施形態は、輻輳統計収集方法及び装置を提供する。方法は、パケットがキューに入ることができないときに、輻輳キューのヘッドパケット長を取得するステップと、前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するステップと、を具備する。前述の技術的解決策によれば、オペレータは、パケット輻輳ポイントを特定でき、サービスを調整してより良いユーザ体験を保証することができる。
2018528737.tif 000002
【特許請求の範囲】
【請求項１】
輻輳統計収集方法であって、
パケットがキューに入ることができないときに、前記キューのヘッドパケット長を取得するステップと、
前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するステップと、
を具備することを特徴とする輻輳統計収集方法。
【請求項２】
前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断する前記ステップの前に、前記方法は、
前記キューの前記ヘッドパケット長がキュートークンバケットの容量より大きい場合に、キューレベル輻輳が発生したと判断するステップ
を具備することを特徴とする請求項１に記載の方法。
【請求項３】
前記方法は、前記キューの前記ヘッドパケット長が前記ＯＮＴトークンバケットの前記容量より小さい場合に、ＰＯＮポートレベル輻輳が発生したと判断するステップをさらに具備することを特徴とする請求項１又は２に記載の方法。
【請求項４】
輻輳統計収集装置であって、
輻輳キューのヘッドパケット長を取得するように構成された取得モジュールと、
前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するように構成されたレート制限モジュールと、
を具備することを特徴とする輻輳統計収集装置。
【請求項５】
前記装置は、
前記キューの前記ヘッドパケット長がキュートークンバケットの容量より大きい場合に、キューレベル輻輳が発生したと判断するように構成されたキューレート制限モジュール
をさらに具備することを特徴とする請求項４に記載の装置。
【請求項６】
前記レート制限モジュールは、前記キューの前記ヘッドパケット長が前記ＯＮＴトークンバケットの前記容量より小さい場合に、ＰＯＮポートレベル輻輳が発生したと判断するようにさらに構成されていることを特徴とする請求項４又は５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信分野に関連し、特に、パケット輻輳統計収集方法及び装置に関する。
【背景技術】
【０００２】
限られたネットワークリソースがより良いネットワークサービスを提供することを保証するために、オペレータは、トラフィックを制限しネットワークリソースの利用効率を向上させるために、ネットワークトラフィックレートを監視して管理する必要がある。この目的を達成するために、ネットワークに入るトラフィックを監視して、ネットワークの輻輳を回避する必要がある。トラフィックがオーバスピードでない場合、デバイスはグリーンカードをパケットに付与し（パケットを緑色に着色する）、この場合は、パケットはブロックされずに転送されることができ、トラフィックがわずかにオーバスピードになると、デバイスは、イエローカードの警告を出し（パケットを黄色に着色する）、この場合は、通常パケットが劣化し、すなわち、パケットの内部優先度が変更され、その後パケットがベストエフォート様式で転送され、又はトラフィックが過度にオーバスピードになると、デバイスは、パブリッシング様式におけるパケットを禁止するレッドカードを与え（パケットを赤色に着色する）、この場合は、パケットの通過が禁止され、すなわち、破棄される。通常、トークンバケットは、パケットレートを推定するために使用される。トークンバケットは、トークンを格納するためのコンテナと考えることができる。特定の容量が事前に設定されており、システムは指定されたレートでトークンをバケットに入れる。バケットがトークンで満たされると、余分なトークンがオーバーフローし、バケットにトークンがそれ以上入らなくなる。トークンバケットは、トークンバケット内のトークンの量がパケット転送のために十分であるかどうかに基づいてトラフィックを推定するために使用される。転送される必要のある各パケットは、通常転送される前に、トークンバケットからいくつかのトークン（パケットサイズに依存する特定の量）を取得する必要がある。バケットが、パケット転送のために使用される十分なトークンを有している場合、トラフィックは、合意された値に準拠しているか、又は一致しているとみなされる。バケットが、パケット転送のために使用される十分なトークンを有していない場合、トラフィックは、合意された値に合致しないか、又は超過しているとみなされる。システムによりトークンをトークンバケットに入れるレート及びトークンバケットの量に応じて、トークンバケットアルゴリズムは３つのモードを有する：シングルレート及びシングルバケット、シングルレート及びダブルバケット、ダブルレート及びダブルバケット。
【０００３】
現在のネットワークデバイスにより使用される階層的サービス品質（Hierarchical Quality of Service, HQoS）機能は、通常、階層スケジューリング様式で実装され、各階層はシェーピング（Shaping）及びレート制限機能をサポートする。例えば、図１に示すように、受動光ネットワーク（Passive Optical Network, PON）ポートのダウンストリームＨＱｏＳ機能は、通常、２つの階層を備える：光ネットワーク端末（Optical Network Terminal, ONT）レベル及びＰＯＮポートレベル。ＯＮＴレベルには８つの優先キューがあり、ＰＯＮポートレベルは、１２８ＯＮＴ又は２５６ＯＮＴをサポートする。キューシェーピング又はＯＮＴシェーピングがイネーブルになった後、エンキューイング（enqueuing）中のパケット破棄に関する統計が収集されると、シングルユーザ（キュー又はＯＮＴ）輻輳により破棄されるのか又はＰＯＮポート輻輳によるのかを判別することができない。
【発明の概要】
【課題を解決するための手段】
【０００４】
このような事情にかんがみて、本発明の実施形態は、オペレータが輻輳原因を特定できないという技術的問題を解消するためのパケット輻輳統計収集方法及び装置を提供する。
【０００５】
第１の態様によれば、パケット輻輳統計収集方法が提供され、輻輳キューのヘッドパケット長を取得するステップと、前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するステップと、を含む。
【０００６】
第１の態様に関連し、第１の態様の第１の可能な実装において、前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断する前記ステップの前に、前記方法は、前記キューの前記ヘッドパケット長がキュートークンバケットの容量より大きい場合に、キューレベル輻輳が発生したと判断するステップを含む。
【０００７】
第１の態様、又は第１の態様の第１の可能な実装に関連し、第１の態様の第２の可能な実装において、前記方法は、前記キューの前記ヘッドパケット長が前記ＯＮＴトークンバケットの前記容量より小さい場合に、ＰＯＮポートレベル輻輳が発生したと判断するステップをさらに含む。
【０００８】
第２の態様によれば、パケット輻輳統計収集装置が提供され、輻輳キューのヘッドパケット長を取得するように構成された取得モジュールと、前記キューの前記ヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するように構成されたレート制限モジュールと、を含む。
【０００９】
第２の態様に関連し、第２の態様の第１の可能な実装において、前記装置は、前記キューの前記ヘッドパケット長がキュートークンバケットの容量より大きい場合に、キューレベル輻輳が発生したと判断するように構成されたキューレート制限モジュールをさらに含む。
【００１０】
第２の態様、又は第２の態様の第１の可能な実装に関連し、第２の態様の第２の可能な実装において、前記レート制限モジュールは、前記キューの前記ヘッドパケット長が前記ＯＮＴトークンバケットの前記容量より小さい場合に、ＰＯＮポートレベル輻輳が発生したと判断するようにさらに構成されている。
【００１１】
前述の技術的解決策によれば、オペレータは、パケット輻輳ポイントを特定でき、サービスを調整して、よりよいユーザ体験を保証することができる。
【００１２】
本発明の実施形態におけるまたは従来技術における技術的解決策をより明確に説明するために、以下で実施形態を説明するために必要な添付の図面について簡単に説明する。以下の説明における添付の図面は本発明のいくつかの実施形態を示すものにすぎず、それでもなお、当業者が創造的な努力なしにこれらの添付の図面から他の図面を得ることができることは明らかである。
【図面の簡単な説明】
【００１３】
【図１】図１は、パッシブ光ネットワークＰＯＮポートのダウンストリームＨＱｏＳ機能の概略的な階層図である。
【図２】図２は、パケットが破棄されたときのｔｒＴＣＭカラーブラインドモードを使用する概略図である。
【図３】図３は、本発明の一実施形態によるパケット輻輳統計収集方法のフローチャートである。
【図４】図４は、本発明の一実施形態によるパケット輻輳統計収集の概略図である。
【図５】図５は、本発明の一実施形態によるパケット輻輳統計収集装置の概略構成図である。
【発明を実施するための形態】
【００１４】
本発明の実施形態における添付の図面を参照しながら、本発明の実施形態における技術的解決策について以下で明確かつ完全に説明する。説明される実施形態は、本発明の実施形態のすべてではなく、単にいくつかの実施形態を示すものにすぎないことは明らかである。本発明の実施形態に基づき当業者が創造的な取り組み無しに得られる他のすべての実施形態は、本発明の保護範囲に含まれるものとする。
【００１５】
現在のネットワークデバイスチップのＨＱｏＳ機能は、通常、１レベルエンティティキュー及び階層スケジューリングの方法を使用して実施され、各階層は、シェーピング及びレート制限機能をサポートすることを理解すべきである。図１に示すように、例えば、ＰＯＮポートのダウンストリームＨＱｏＳ機能は、通常、２つの階層を備える：ＯＮＴレベルとＰＯＮポートレベル。ＯＮＴレベルには８つの優先キューがあり、ＰＯＮポートレベルは、１２８ＯＮＴ又は２５６ＯＮＴをサポートする。キューシェーピング機能又はＯＮＴシェーピング機能がイネーブルになった後、エンキューイング（enqueuing）中のパケット破棄に関する統計が収集されると、キュー又はＯＮＴ輻輳により破棄されるのか、又はＰＯＮポート輻輳によるのかを判別することができない。本発明の実施形態は、技術的問題の解決策を提供する。
【００１６】
当業者であれば、シェーピング及びレート制限は、通常、キュー及びトークンバケットを使用することによって実施されることが分かっている。一例としてシングルレート及びシングルバケットを使用して説明する。本発明の実施形態は、別のトークンバケットのレート制限方法にも適用可能であることを理解すべきである。
【００１７】
レート制限目的を達成するためには、専用アクセスレート（Committed Access Rate, CAR）を達成するために、ネットワークに入るトラフィック（すなわちパケット）は、監視される必要がある。ＣＡＲは、ネットワーク輻輳の原因とならないように、合意された範囲内でネットワークに入るユーザトラフィックのレートを制限している。ＣＡＲを達成するためには、トラフィックが推定される必要があり、その後推定結果に従って、対応する動作が実行される。
【００１８】
トラフィックがオーバスピードでない場合、デバイスはグリーンカードをパケットに付与し、この場合は、パケットはブロックされず、すなわち、転送される。
【００１９】
トラフィックがわずかにオーバスピードになると、デバイスは、イエローカードの警告を出し、この場合は、通常パケットが劣化し、すなわち、パケットの内部優先度が変更され、その後パケットがベストエフォート様式で転送される。
【００２０】
トラフィックが過度にオーバスピードになると、デバイスは、パブリッシング様式におけるパケットを禁止するレッドカードを与え、パケットの通過が禁止され、すなわち、破棄される。
【００２１】
認定バーストサイズ（Committed Burst Size, CBS）は、トークンバケットの容量、すなわち、バケットＣを瞬時に通過することができる認定バーストトラフィックを示す。シングルレート・シングルバケットモードにおいて、システムは、認定情報レート（Committed Information Rate, CIR）でバケットＣにトークンを置く。ＣＩＲは、バケットＣがパケットを送信または転送できる平均レートである。使用可能なトークンの総量（Tcと表示）がＣＢＳより少ない場合、トークンの量は、増加し続け、トークンバケットがいっぱいになるとトークンの量はそれ以上増加しない。
【００２２】
到着したパケット（パケット長をＢとする）に対し、ＢがＴｃより小さい場合には、パケットはグリーンにマークされ、Ｔｃは、Ｂにより減り、又はＢがＴｃより大きい場合には、パケットはレッドにマークされ、Ｔｃは減らない。最初に到着したパケットが１５００バイトであると仮定する。バケットＣがチェックされているとき、トークンの量がパケット長より大きいことが分かる。したがって、パケットがグリーンにマークされ、１５００バイトのトークンがバケットＣから減り、残り５００バイトとなる（トークンバケットは初期状態において２０００バイトのトークンを有すると仮定する）。１ミリ秒後に到着する２番目のパケットは１５００バイトであると仮定する。この間隔内で、１２５バイトの新しいトークンがバケットＣに追加される（すなわち、ＣＩＲは、１２５バイト／ミリ秒）。元の残りの５００バイトのトークンに１２５バイトが追加され、この場合において、バケットＣは、合計６２５バイトを有する。トークンの量は、十分ではなく、パケットはレッドにマークされる。
【００２３】
さらに１ミリ秒後に到着した３番目のパケットは１０００バイトであると仮定する。この間隔内で、１２５バイトの新しいトークンがバケットＣに追加される。元の残りの６２５バイトに１２５バイトが追加され、この場合において、バケットＣは、合計７５０バイトを有する。トークンの量は十分ではなく、したがって、パケットはレッドにマークされる。２０ミリ秒後に到着した４番目のパケットは１５００バイトであると仮定する。この間隔内で、２５００バイトの新しいトークンがバケットＣに追加される。元の残りの７５０バイトに２５００バイトが追加され、この場合において、バケットＣにおけるトークンの量は３２５０バイトである。しかし、ＣＢＳが２０００バイトであるため、したがって、１２５０バイトのトークンがオーバーフローし、破棄される。この場合において、バケットＣにおけるトークンの量は、パケット長より大きく、パケットはグリーンにマークされ、１５００バイトのトークンが、バケットＣから減り、残りの５００バイトが存在する。
【００２４】
パケット処理プロセスを次の表１に示す。
【００２５】
【表１】
2018528737.tif 000003
【００２６】
キュー内にキャッシュされたパケットがデキュー（dequeue）する必要がある場合に、パケット長がトークンバケットの容量より大きい場合には、パケットはデキューできず、キューキャッシュ内で待機し続ける必要があることを理解すべきである。新たに到着したパケットは、キューキャッシュに入り、キューキャッシュがいっぱいの場合には、新たに到着したパケットはキューに入ることができず、新たに到着したパケットは、破棄される。本発明のこの実施形態の目的は、どのレベルの輻輳がパケットの破棄の原因となるかという事実に関する統計を収集することである。
【００２７】
理解を容易にするために、シェーピング及びレート制限アルゴリズムの例としてｔｒＴＣＭトークンバケットが使用される。ｔｒＴＣＭアルゴリズムは、標準RFC2698において定義されており、レート制限アルゴリズムはここでは詳細に説明しない。
【００２８】
ｔｒＴＣＭレート制限アルゴリズムでは、図２に示すように、パケット長がＰＢＳバケット深さ（depth）より小さく、ＣＢＳバケット深さより大きい場合、パケットは、通常デキューでき、イエローにマークされる。この場合、新しいＰＢＳバケット深さは、元のＰＢＳバケット深さからパケット長を引くことにより得られる深さである。パケット長がＰＢＳバケット深さより小さく、ＣＢＳバケット深さより小さい場合、パケットは通常デキューでき、グリーンにマークされる。新たなＰＢＳバケット深さは、元のＰＢＳバケット深さからパケット長を引くことにより得られる深さであり、新たなＣＢＳバケット深さは、元のＣＢＳバケット深さからパケット長を引いた深さである。
【００２９】
以下では、図３に示すように、キューキャッシュがいっぱいになり、新たに到着したパケットがエンキューできず破棄される場合に、どのレベルのパケット破棄が生じるかに関する統計をどのように収集するかについて特に説明する。本発明の一実施形態は、以下のステップを含むパケット輻輳統計収集方法を提供する。
【００３０】
ステップ３０１：パケットがキューに入ることができないときに、キューのヘッドパケット長を取得する。
【００３１】
ステップ３０２：キューのヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴ輻輳が発生したと判断する。
【００３２】
任意選択で、ステップＳ３０２の前に、方法は、
キューに対し、シェーピング及びレート制限機能が設定され、キューのヘッドパケット長が現在のキュートークンバケットの容量より大きいことが判断された場合に、キューレベル輻輳が発生したとの判断をさらに含む。
【００３３】
任意選択で、方法はさらに以下を含む。
【００３４】
ステップ３０３：キューのヘッドパケット長が現在のＯＮＴトークンバケットの容量より小さい場合に、ＰＯＮポート輻輳を記録する。
【００３５】
これに対し、図４は、本発明の一実施形態によるパケット輻輳統計収集の概略図である。この概略図は、本発明のこの実施形態における２つのレベルのスケジューリング、すなわち、ＯＮＴレベル及びＰＯＮポートレベルを、直感的かつ簡単に表示する。新たに到着したパケットがサービスエンティティキューに入れない場合には、パケット破棄が生じる。前述の技術的解決策によれば、オペレータは、パケット輻輳ポイントを特定でき、サービスを調整してよりよいユーザ体験を保証することができる。
【００３６】
本発明の実施形態は、輻輳統計収集装置をさらに提供し、図５に示すように、装置は、
パケットがキューに入ることができないときに、キューのヘッドパケット長を取得するように構成された取得モジュール５１０と、
キューのヘッドパケット長が光ネットワーク端末ＯＮＴトークンバケットの容量より大きい場合に、ＯＮＴレベル輻輳が発生したと判断するように構成されたレート制限モジュール５２０と、
を含む。
【００３７】
任意選択で、装置は、
キューのヘッドパケット長がキュートークンバケットの容量より大きい場合に、キューレベル輻輳が発生したと判断するように構成されたキューレート制限モジュールをさらに含む。
【００３８】
任意選択で、装置は、
キューのヘッドパケット長がＯＮＴトークンバケットの容量より小さい場合に、ＰＯＮポートレベル輻輳が発生したと判断するように構成されたＰＯＮポートレート制限モジュールを含む。
【００３９】
好適には、本発明のこの実施形態において提供される装置は、エンティティに関して、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array, FPGA）であっても、特定用途向け集積回路（Application Specific Integrated Circuit, ASIC）であっても、システムオンチップ（System on Chip, SoC）であっても、中央処理装置（Central Processing Unit, CPU）であっても、ネットワークプロセッサ（Network Processor, NP）であっても、デジタル信号処理回路（Digital Signal Processor, DSP）であっても、マイクロ・コントローラ・ユニット（Micro Controller Unit, MCU）であっても、プログラマブルコントローラ（Programmable Controller, PC）又は別の集積チップであってもよい。
【００４０】
当業者は、本発明の各態様又は各態様の可能な実装が、システム、方法、又はコンピュータプログラム製品として具体的に実施され得ることを理解し得る。したがって、本発明の各態様又は各態様の可能な実装は、本明細書で「回路」、「モジュール」、又は「システム」と統一してよばれる、ハードウェアのみの実施形態、ソフトウェアの実施形態（ファームウェア、常駐ソフトウェアなどを含む）、又はソフトウェアとハードウェアの組み合わせを備えた実施形態の形式を使用することができる。加えて、本発明の各態様又は各態様の可能な実装は、コンピュータプログラム製品の形態をとることができ、コンピュータプログラム製品は、コンピュータ可読媒体に格納されたコンピュータ可読プログラムコードである。
【００４１】
コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読記憶媒体であってよい。コンピュータ可読記憶媒体は、ランダムアクセスメモリ（RAM）、読み出し専用メモリ（ROM）、消去可能プログラマブル読み出し専用メモリ（EPROM又はフラッシュメモリ）、光ファイバ、及びコンパクトディスク読み出し専用メモリ（CD-ROM）などの、電子、磁気、光学、電磁気、赤外線、又は半導電性システム、デバイス、又は装置、又はそれらの任意の適切な組み合わせを含むがこれに限定されない。
【００４２】
コンピュータ内のプロセッサは、プロセッサが、フローチャートの各ステップ又はステップの組み合わせにおいて指定される機能及び動作を実行できるように、コンピュータ可読媒体に格納されたコンピュータ可読プログラムコードを読み出し、ブロック図における各ブロック又はブロックの組み合わせにおいて指定される機能及び動作を実施する装置が生成される。
【００４３】
すべてのコンピュータ可読プログラムコードは、ユーザコンピュータ上で実行されてよく、又は一部はスタンドアロンソフトウェアパッケージとしてユーザコンピュータ上で実行されてもよく、又は、一部がリモートコンピュータで実行されている間、一部がコンピュータ上で実行されてもよく、又はすべてのコードがリモートコンピュータ又はサーバ上で実行されてもよい。いくつかの代替実施解決策において、ブロック図における各ブロックにおいて指定されるフローチャート又は機能の各ステップは、図示された順序で生じないことがあり得ることにも留意すべきである。例えば、関連する機能によって決まる図中の２つの連続するステップ又は２つのブロックは、実質的に同時に実行されてよく、又はこれらのブロックは時には逆の順序において実行されてもよい。
【００４４】
当業者であれば、本明細書に開示された実施形態に記載された実施例と組み合わせて、ユニット及びアルゴリズムステップは、電子ハードウェア、又はコンピュータソフトウェアと電子ハードウェアとの組み合わせにより実施されてもよいことが分かり得る。機能がハードウェアにより又はソフトウェアにより実行されるかは、技術的解決策の具体的なアプリケーション及び設計制約条件に依存する。当業者であれば、特定のアプリケーションごとに記載された機能を実施するために異なる方法を使用することができるが、その実施は本発明の範囲を超えていると考えるべきではない。
【００４５】
最後に、前述の実施形態が、単に、本発明の技術的解決策を説明するためのものであって、本発明を限定するためのものではないことに留意されたい。本発明が、前述の実施形態を参照して詳細に説明されたが、当業者は、彼が前述の実施形態において説明された技術的解決策に対する変更を行い、あるいは、技術的解決策のいくつかのまたはすべての技術的特徴等に対する同等の置換を行うことができることを理解するに違いない。したがって、本発明の保護範囲は、特許請求の範囲の保護範囲に従うものとする。
【符号の説明】
【００４６】
３０１    ステップ
３０２    ステップ
３０３    ステップ
５１０    取得モジュール
５２０    レート制限モジュール
【図１】
2018528737.tif 000004
【図２】
2018528737.tif 000005
【図３】
2018528737.tif 000006
【図４】
2018528737.tif 000007
【図５】
2018528737.tif 000008
【国際調査報告】
2018528737.tif 000009
2018528737.tif 000010
2018528737.tif 000011
2018528737.tif 000012