(57)【要約】【課題】中継ネットワークにおいて、接続先の通信装置へバースト的に到着する処理要求パケットを分散させる。【解決手段】ＮＷコントローラ６のデータ収集部は、Ｌ２ＮＷ４を構成するＬ２ＳＷ５から、当該Ｌ２ＳＷ５へ入力されたパケットを観測して得られた、アプリケーションサーバ２宛てのセッション要求パケットのトラヒック量を示す上り観測データと、アプリケーションサーバ２が送信したセッション応答パケットのトラヒック量を示す下り観測データとを収集する。制御部は、上り観測データが示すトラヒック量と下り観測データが示すトラヒック量との比、又は、上り観測データから得られるトラヒック量の増分と下り観測データから得られるトラヒック量の増分との比に基づいて、Ｌ２ＮＷ４を構成するＬ２ＳＷ５に対してアプリケーションサーバ２宛てのパケットのシェーピングレートを変更する。【選択図】図１
2020017806.tif 000002
【特許請求の範囲】
【請求項１】
１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集部と、
前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御部と、
を備えるネットワーク制御装置。
【請求項２】
前記トラヒック量は、前記中継装置への入力データレート、入力データ量又は入力パケット数である、
請求項１に記載のネットワーク制御装置。
【請求項３】
前記制御部は、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときには前記シェーピングレートを減少させ、終了を検出したときには前記シェーピングレートを増加させるよう制御する、
請求項１又は請求項２に記載のネットワーク制御装置。
【請求項４】
前記制御部は、前記上り観測データが示す前記トラヒック量と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、前記上り観測データから得られる前記トラヒック量の増分と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生を検出する、
請求項３に記載のネットワーク制御装置。
【請求項５】
前記制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、前記中継ネットワークを構成する前記中継装置のうち前記第二通信装置に近い前記中継装置から順に前記シェーピングレートの変更依頼を送信する、
請求項１から請求項４のいずれか一項に記載のネットワーク制御装置。
【請求項６】
前記中継ネットワークは、レイヤ２ネットワークであり、
前記中継装置は、レイヤ２スイッチである、
請求項１から請求項５のいずれか一項に記載のネットワーク制御装置。
【請求項７】
前記処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、
前記応答パケットは、前記セッション要求パケットへの応答を示すセッション応答パケットである、
請求項１から請求項６のいずれか一項に記載のネットワーク制御装置。
【請求項８】
１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集ステップと、
前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御ステップと、
を有するネットワーク制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク制御装置及びネットワーク制御方法に関する。
【背景技術】
【０００２】
近年、増加するモバイルトラヒックを効率的に収容するため、Centralized Radio Access Network（Ｃ−ＲＡＮ）構成が検討されている（例えば、非特許文献１参照）。Ｃ−ＲＡＮでは、多数のRadio Equipment（ＲＥ）が高密度で配置され、集約配置されたRadio Equipment Controls（ＲＥＣｓ）に接続される。また、ＩＥＥＥ  ８０２．１ＣＭにおいて、フロントホールのトラヒックをレイヤ２（以下、Ｌ２と記載）ネットワークに収容する検討が進められている（例えば、非特許文献２参照）。一方で、Internet of Things（ＩｏＴ）の一部に代表される、遅延を許容するトラヒック（遅延許容トラヒック）をアクセスネットワークに収容する検討も進められている。これらを鑑みて、フロントホール、バックホールに加え、遅延許容トラヒックを同一のＬ２ネットワーク（Ｌ２ＮＷ）に収容したマルチサービス収容アクセスネットワークを検討した報告がなされている（例えば、非特許文献３参照）。
【０００３】
Ｌ２ＮＷを流れるサービスのフローの中には、多数の端末からネットワーク上のアプリケーションサーバに同時に接続するものがある。これら同時接続により、接続先サーバが、端末からバースト的に到着するパケットを処理できなくなることがある。バースト的に到着するパケットの一例として端末からのセッション要求パケットが考えられるため、以降は、バースト的に到着するパケットがセッション要求パケットである場合を例に記載する。一般に図２１に示すように、各Ｌ２スイッチ（Ｌ２ＳＷ）では、ネットワーク上のサーバが処理能力を超える数のセッション要求パケットを受け付けないように、Ｌ２ＳＷを流れるフローのシェーピングにより、各宛先へのトラヒックは平滑化されている。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】"ドコモ5Gホワイトペーパー"，［online］，2014年9月，株式会社ＮＴＴドコモ，［平成30年6月29日検索］，インターネット〈https://www.nttdocomo.co.jp/corporate/technology/whitepaper_5g/〉
【非特許文献２】Craig Gunther，"What's New in the World of IEEE 802.1 TSN"，Standards News，IEEE Communications Magazine，Communications Standards Supplement，2016年9月，p.12-15
【非特許文献３】久保  尊広，外6名，"マルチサービスを収容したL２ネットワークにおける遅延の評価"，2016年電子情報通信学会通信ソサイエティ大会，2016年9月，B-8-25，p.155
【発明の概要】
【発明が解決しようとする課題】
【０００５】
図２２に示すように、サーバの処理能力が一時的に枯渇している場合には、図２１に示す通常時よりも、サーバにおける処理可能パケット数の閾値が低下する。そのため、サーバへのセッション要求パケットのフローが正常なレートであっても、サーバは、受信したパケットを、処理能力の枯渇前よりも多く廃棄する可能性がある。このような状況では、サーバにおいてパケット処理が行えずにパケットの廃棄が発生しているにもかかわらず、Ｌ２ＮＷにおいて処理要求パケットを分散させることができないという問題があった。
【０００６】
上記事情に鑑み、本発明は、中継ネットワークにおいて、接続先の通信装置へバースト的に到着する処理要求パケットを分散させることができるネットワーク制御装置及びネットワーク制御方法を提供することを目的としている。
【課題を解決するための手段】
【０００７】
本発明の一態様は、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集部と、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御部と、を備えるネットワーク制御装置である。
【０００８】
本発明の一態様は、上述のネットワーク制御装置であって、前記トラヒック量は、前記中継装置への入力データレート、入力データ量又は入力パケット数である。
【０００９】
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときには前記シェーピングレートを減少させ、終了を検出したときには前記シェーピングレートを増加させるよう制御する。
【００１０】
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、前記上り観測データが示す前記トラヒック量と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、前記上り観測データから得られる前記トラヒック量の増分と、前記第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、前記第二通信装置宛ての前記処理要求パケットのバーストトラヒックの発生を検出する。
【００１１】
本発明の一態様は、上述のネットワーク制御装置であって、前記制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、前記中継ネットワークを構成する前記中継装置のうち前記第二通信装置に近い前記中継装置から順に前記シェーピングレートの変更依頼を送信する。
【００１２】
本発明の一態様は、上述のネットワーク制御装置であって、前記中継ネットワークは、レイヤ２ネットワークであり、前記中継装置は、レイヤ２スイッチである。
【００１３】
本発明の一態様は、上述のネットワーク制御装置であって、前記処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、前記応答パケットは、前記セッション要求パケットへの応答を示すセッション応答パケットである。
【００１４】
本発明の一態様は、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継するネットワークシステムにおける前記中継装置から、当該中継装置へ入力されたパケットを観測して得られた、前記第一通信装置から前記第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、前記第二通信装置が前記処理要求パケットに対応して送信した応答パケットのトラヒック量を示す下り観測データとを収集するデータ収集ステップと、前記上り観測データが示す前記トラヒック量と前記下り観測データが示す前記トラヒック量との比、又は、前記上り観測データから得られる前記トラヒック量の増分と前記下り観測データから得られる前記トラヒック量の増分との比に基づいて、前記中継ネットワークを構成する前記中継装置に対して前記第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する制御ステップと、を有するネットワーク制御方法である。
【発明の効果】
【００１５】
本発明により、中継ネットワークにおいて、接続先の通信装置へバースト的に到着する処理要求パケットを分散させることが可能となる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態によるネットワークシステムの構成を示す図である。
【図２】同実施形態によるＬ２ＮＷの構成を示す図である。
【図３】同実施形態によるネットワークシステムの他の構成を示す図である。
【図４】同実施形態によるＬ２ＳＷの構成例を示すブロック図である。
【図５】同実施形態によるＮＷコントローラの構成を示すブロック図である。
【図６】同実施形態によるホップ数データを示す図である。
【図７】同実施形態による上り観測データを示す図である。
【図８】同実施形態による下り観測データを示す図である。
【図９】同実施形態によるＬ２ＮＷにおけるセッション要求パケットとセッション応答パケットの流れを示す図である。
【図１０】同実施形態によるセッション要求パケットの入力データレートとの比較に用いられるセッション応答パケットの入力データレートのタイミングを示す図である。
【図１１】同実施形態によるＮＷコントローラがＬ２ＳＷにシェーピング設定を行うシーケンス図である。
【図１２】同実施形態によるネットワークシステムのシェーピング開始処理を示すフロー図である。
【図１３】同実施形態によるネットワークシステムのシェーピング終了処理を示すフロー図である。
【図１４】第２の実施形態による前周期上り観測データを示す図である。
【図１５】同実施形態による上り増分データを示す図である。
【図１６】同実施形態による前周期下り観測データを示す図である。
【図１７】同実施形態による下り増分データを示す図である。
【図１８】同実施形態によるセッション要求パケットの入力データレート増分との比較に用いられるセッション応答パケットの入力データレート増分のタイミングを示す図である。
【図１９】第３の実施形態による処理能力データを示す図である。
【図２０】同実施形態によるネットワークシステムのシェーピング開始処理を示すフロー図である。
【図２１】従来技術によるパケットのシェーピングを示す図である。
【図２２】従来技術によるＬ２ＮＷにおけるバーストトラヒック発生を示す図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照しながら本発明の実施形態を詳細に説明する。本実施形態は、Ｌ２のネットワークの技術に関する。具体的には、本実施形態は、１以上のサービスが収容されるＬ２ＮＷと接続されるアプリケーションサーバ負荷検出に関する。
【００１８】
本実施形態では、端末と、アプリケーションサーバとが、Ｌ２ＮＷを介して通信する。Ｌ２ＮＷは、Ｌ２ＳＷにより構成される。端末からアプリケーションサーバの方向を上り、アプリケーションサーバから端末の方向を下りと記載する。ネットワークコントローラ（ＮＷコントローラ）は、端末からアプリケーションサーバ宛の処理要求パケットのトラヒックデータとアプリケーションサーバからの応答パケットのトラヒックデータとを、Ｌ２ＳＷから周期的に収集する。処理要求パケットは、アプリケーションサーバへ処理を要求するパケットであり、応答パケットは、処理要求パケットに対する応答として送信される。本実施形態では、処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、応答パケットは、セッション要求パケットに対する応答を示すセッション応答パケットである場合を例に説明する。ＮＷコントローラは、収集したトラヒックデータを用いて、アプリケーションサーバにおける処理能力の枯渇又はバーストトラヒックの発生を検出する。具体的には、ＮＷコントローラは、Ｌ２ＳＷにおけるセッション要求パケットとセッション応答パケットとの間の入力データレートの比、入力データ量の比、入力パケット数の比、又は、入力データレート増分の比に基づいて検出を行う。あるいは、ＮＷコントローラは、セッション要求パケットの入力データレート、入力データ量、又は、入力データレート増分と、アプリケーションサーバが処理可能なそれらの上限値との比較に基づいて検出を行う。
【００１９】
ＮＷコントローラは、Ｌ２ＮＷを構成するＬ２ＳＷのうち、処理能力の枯渇又はバーストトラヒックの発生が検出されたアプリケーションサーバになるべく近いＬ２ＳＷに対して、そのアプリケーションサーバ宛ての全てのパケット又はセッション要求パケットのフロー（トラヒックの流れ）の送信レートを減少させるようシェーピングレートを設定する。シェーピングレートは、Ｌ２ＳＷにおいて入力したパケットを通過させる速さである。これにより、アプリケーションサーバに同時に到着するセッション要求パケットを抑制する。そして、ＮＷコントローラは、収集したトラヒックデータを用いて、アプリケーションサーバにおける処理能力が枯渇から回復した、又は、バーストトラヒックの発生が終了したと判断した場合、シェーピングレートを増加させ、元に戻す。
【００２０】
従来は、各Ｌ２ＳＷにおいてパケットの輻輳を把握し、輻輳を把握したＬ２ＳＷが自装置におけるシェーピングレートを低減していた。そのため、アプリケーションサーバが処理可能なセッション要求パケットのトラヒック量となるようにＬ２ＮＷ全体のパケットのフローを制御することは困難な場合があった。本実施形態によれば、ＮＷコントローラは、アプリケーションサーバと直接通信することなく、アプリケーションサーバのセッション要求パケットの処理能力の状態やバーストトラヒックの発生を把握し、Ｌ２ＮＷ全体におけるセッション要求パケットのフローを低減させるように、Ｌ２ＳＷにおけるシェーピングレートの変更が可能となる。従って、アプリケーションサーバへのセッション要求パケットの到着を分散させ、アプリケーションサーバにおけるパケット廃棄や遅延許容トラヒックの再送を防ぎ、ネットワーク利用効率を向上させることが可能となる。以下、詳細な実施形態を説明する。
【００２１】
（第１の実施形態）
図１は、本発明の第１の実施形態によるネットワークシステム１の構成を示す図である。ネットワークシステム１は、アプリケーションサーバ２と、端末３と、Ｌ２ＮＷ４と、Ｌ３ＮＷ（レイヤ３ネットワーク）７とを有する。ネットワークシステム１が複数のアプリケーションサーバ２を備える場合、各アプリケーションサーバ２はそれぞれ、異なるサービスを提供し得る。ネットワークシステム１が備えるＪ台（Ｊは１以上の整数）のアプリケーションサーバ２のうちｊ台目（ｊは１以上Ｊ以下の整数）のアプリケーションサーバ２を、アプリケーションサーバ２−ｊ又はアプリサーバ＃ｊとも記載する。同図では、ネットワークシステム１は、２台（Ｊ＝２）のアプリケーションサーバ２−１及び２−２を備えている。アプリケーションサーバ２−１はサービスＡを提供し、アプリケーションサーバ２−２はサービスＢを提供する。また、Ｌ２ＮＷ４と接続される複数の端末３には、サービスＡを利用する端末３、サービスＢを利用する端末３、その他のサービスを利用する端末３がある。
【００２２】
アプリケーションサーバ２と端末３とは、Ｌ２ＮＷ４及びＬ３ＮＷ（レイヤ３ネットワーク）７を介して接続されている。Ｌ２ＮＷ４は、１台以上のＬ２ＳＷ５から構成される。Ｌ２ＮＷ４を構成するＮ台のＬ２ＳＷ５のうちｎ台目（ｎは１以上Ｎ以下の整数）のＬ２ＳＷ５を、Ｌ２ＳＷ＃ｎとも記載する。なお、アプリケーションサーバ２と端末３とは、Ｌ３ネットワークを介さずに直接Ｌ２ＮＷ４と接続されていてもよい。Ｌ２ＮＷ４は、さらに、ＮＷコントローラ６を備える。ＮＷコントローラ６は、各Ｌ２ＳＷ５と接続される。ＮＷコントローラ６とＬ２ＳＷ５とを統合した装置としてもよい。例えば、ＮＷコントローラ６は、Ｌ２ＳＷ５と同じ筐体に納められてもよい。ＮＷコントローラ６がＬ２ＳＷ５と同じ筐体に収められており、かつ、高速な処理が必要な場合は、各Ｌ２ＳＷ５にハードウェアとしてＮＷコントローラ６が実装される構成が考えられる。また、ＮＷコントローラ６は、Ｌ２ＮＷ４の外部の装置でもよい。また、Ｌ２ＮＷ４は、図２に示すＬ２ＮＷ４ａのような構成でもよい。
【００２３】
図２は、Ｌ２ＮＷ４ａの構成を示す図である。同図に示すように、Ｌ２ＮＷ４ａは、幹線リングＲ１と、支線リングＲ２−１、Ｒ２−２との階層構造になっている。幹線リングＲ１、支線リングＲ２−１、Ｒ２−２はそれぞれ、リング状に接続される複数台のＬ２ＳＷ５からなる。幹線リングＲ１と支線リングＲ２−１とは１台のＬ２ＳＷ５で接続され、幹線リングＲ１と支線リングＲ２−２とは他の１台のＬ２ＳＷ５で接続される。幹線リングＲ１を構成するＬ２ＳＷ５は１台目のＮＷコントローラ６であるＮＷコントローラ＃１と接続され、支線リングＲ２−１を構成するＬ２ＳＷ５は２台目のＮＷコントローラ６であるＮＷコントローラ＃２と接続され、支線リングＲ２−２を構成するＬ２ＳＷ５は３台目のＮＷコントローラ６であるＮＷコントローラ＃３と接続される。このように、幹線と支線のそれぞれ配置された複数のＮＷコントローラ６が制御を行う形態も可能である。
【００２４】
図３は、ネットワークシステム１ｂの構成を示す図である。図１に示すネットワークシステム１に代えて、同図に示すネットワークシステム１ｂを用いてもよい。同図に示すネットワークシステム１ｂが、図１に示すネットワークシステム１と異なる点は、Ｌ２ＮＷ４に代えてＬ２ＮＷ４ｂを備える点である。ＮＷコントローラ６は、Ｌ２ＮＷ４ｂを構成するＬ２ＳＷ５のうち、一部のＬ２ＳＷ５と接続される。ＮＷコントローラ６と接続されないＬ２ＳＷ５として、従来のＬ２ＳＷを用いることができる。このように、ＮＷコントローラ６が通信及び制御を行うことができないＬ２ＳＷ５があってもよい。
【００２５】
図４は、Ｌ２ＳＷ５の構成例を示すブロック図である。Ｌ２ＳＷ５は、第１ポート５１、マッチング部５２、カウンタ部５３、キュー５４、シェーパー５５、第２ポート５６、通知部５７及び制御部５８を備える。マッチング部５２、カウンタ部５３、キュー５４、シェーパー５５については、上りパケットに関してのみ記載している。
【００２６】
Ｌ２ＳＷ５は、第１ポート５１を１以上備える。第１ポート５１は、端末３、又は、下流の他のＬ２ＳＷ５から上りのパケットを入力する。マッチング部５２は、入力した上りのパケットの分別を行う。具体的には、マッチング部５２は、パケットに設定されている例えばヘッダのデータを参照し、パケットの宛先と、パケットの種類を判定する。パケットの種類は、セッション要求パケットであるか否かを示す。
【００２７】
カウンタ部５３は、マッチング部５２によるパケットの分別ごとにパケットのビット数をカウントする。これにより、カウンタ部５３は、宛先のアプリケーションサーバ２及びパケットの種別ごとに、各観測周期における上りパケットのトラヒック量を計測する。観測周期は、バーストトラヒックの立ち上がりが判断できる時間間隔に設定する。トラヒック量は、入力データレートにより表される。入力データレートとは、１観測周期において入力したパケットのビット数を、１観測周期に相当する時間により除算した値である。カウンタ部５３は、トラヒック量としてさらに観測周期ごとの入力データ量や入力パケット数を計数してもよい。入力データ量とは、入力したパケットのビット数、バイト数などである。
【００２８】
Ｌ２ＳＷ５は、キュー５４を１以上備える。例えば、Ｌ２ＳＷ５は、優先度別の複数のキュー５４を備えてもよい。キュー５４は、第１ポート５１から入力した上りパケットを一時的にストア（バッファリング）する。セッション要求パケットをストアするキュー５４と、データパケットをストアするキュー５４とは同一でもよく、異なっていてもよい。シェーパー５５は、キュー５４がストアしている上りパケットを、設定されたシェーピングレートに従って例えば優先度に応じて読み出し、第２ポート５６へ出力する。
【００２９】
Ｌ２ＳＷ５は、第２ポート５６を１以上備える。第２ポート５６は、上流の他のＬ２ＳＷ５又はアプリケーションサーバ２に、キュー５４から読み出した上りパケットを出力する。
【００３０】
Ｌ２ＮＷ４は、アプリケーションサーバ２から端末３宛ての下りパケットを転送するため、下り方向についてマッチング部５２、カウンタ部５３、キュー５４及びシェーパー５５と同様の構成を有する（図示せず）。下り方向用のマッチング部５２（図示せず）は、第２ポート５６からが受信した下りパケットに設定されている例えばヘッダのデータを参照し、送信元のアプリケーションサーバ２と、パケットの種類を判定する。パケットの種類は、セッション応答パケットであるか否かを示す。下り方向用のカウンタ部５３（図示せず）は、下り方向用のマッチング部５２がマッチングした送信元のアプリケーションサーバ２及びパケットの種別ごとに下りパケットのトラヒック量を計測する。下り方向用のキュー５４（図示せず）は、下りパケットを一時的にストアする。下り方向用のシェーパー５５（図示せず）は、下り方向用のキュー５４（図示せず）がストアしている下りパケットを優先度に応じて読み出し、第１ポート５１を介して下流のＬ２ＳＷ５又は端末３へ出力する。
【００３１】
通知部５７は、上りパケット観測データ及び下りパケット観測データを設定した観測データを、ＮＷコントローラ６に定期的に通知する。上りパケット観測データは、１観測周期に観測された宛先のアプリケーションサーバ２及びパケットの種別ごとの上りパケットのトラヒック量を示す。下りパケット観測データは、１観測周期に観測された送信元のアプリケーションサーバ２及びパケットの種別ごとの下りパケットのトラヒック量を示す。制御部５８は、各機能部を制御する。制御部５８は、シェーパー５５におけるシェーピングを制御する。
【００３２】
図５は、ＮＷコントローラ６の構成を示すブロック図である。ＮＷコントローラ６は、記憶部６１と、データ収集部６２と、制御部６３とを備える。記憶部６１は、ホップ数データと、各Ｌ２ＳＷ５における観測データを記憶する。ホップ数データは、各アプリケーションサーバ２と各Ｌ２ＳＷ５との間のホップ数を示す。データ収集部６２は、各Ｌ２ＳＷ５から定期的に観測データを収集し、記憶部６１に保存する。
【００３３】
制御部６３は、シェーピング開始制御部６３１と、シェーピング終了制御部６３２とを備える。シェーピング開始制御部６３１は、観測データを参照して、アプリケーションサーバ２毎に、セッション要求パケットの入力データレートと、セッション応答パケットの入力データレートとの比を算出する。シェーピング開始制御部６３１は、算出した比に基づいて、アプリケーションサーバ２における処理能力の一時的な枯渇又はアプリケーションサーバ２宛てのバーストトラヒックの発生を検出する。シェーピング開始制御部６３１は、検出されたアプリケーションサーバ２宛ての上りパケットのトラヒック量を低減するようにシェーピングレートの変更をＬ２ＳＷ５に指示する。このとき、シェーピング開始制御部６３１は、ホップ数データを参照し、アプリケーションサーバ２との間のホップ数が少ないＬ２ＳＷ５を優先して指示対象とする。
【００３４】
シェーピング終了制御部６３２は、観測データを参照して、アプリケーションサーバ２毎に、セッション要求パケットの入力データレートと、セッション応答パケットの入力データレートとの比を算出する。シェーピング終了制御部６３２は、算出した比に基づいて、アプリケーションサーバ２における処理能力の一時的な枯渇からの回復又はアプリケーションサーバ２宛てのバーストトラヒックの終了を検出する。シェーピング終了制御部６３２は、検出されたアプリケーションサーバ２宛ての上りパケットのトラヒック量を増加させるようにシェーピングレートの変更をＬ２ＳＷ５に指示する。
【００３５】
図６は、ホップ数データの例を示す図である。ホップ数データは、アプリケーションサーバ２の識別情報と、当該アプリケーションサーバ２から各Ｌ２ＳＷまでのホップ数とを示す。アプリケーションサーバ２の識別情報として、アプリケーションサーバ２のInternet Protocol（ＩＰ）アドレスを用いることができる。
【００３６】
図７は、上り観測データの例を示す図である。同図に示す上り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、１観測周期においてＬ２ＳＷ５が観測（計測）した上りパケットの入力データレート及び入力データ量を示す。パケット種別は、セッション要求パケットであるか否かにより表される。セッション要求パケットである場合は「１」、セッション要求パケット以外の場合は「０」が設定される。
【００３７】
図８は、下り観測データの例を示す図である。同図に示す下り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、１観測周期においてＬ２ＳＷ５が観測（計測）した下りパケットの入力データレート及び入力データ量を示す。パケット種別は、セッション応答パケットであるか否かにより表される。セッション応答パケットである場合は「１」、セッション応答パケット以外の場合は「０」が設定される。
【００３８】
図９は、Ｌ２ＮＷ４におけるセッション要求パケットとセッション応答パケットの流れを示す図である。同図に示すように、Ｌ２ＳＷ５は、中継したセッション要求パケットに対するアプリケーションサーバ２からのセッション応答パケットを、Ｔ＿ＲＴＴ経過後に受信する。Ｔ＿ＲＴＴは、Ｌ２ＳＷ５からアプリケーションサーバ２までの往復伝搬遅延と、Ｌ２ＳＷ５における処理遅延と、アプリケーションサーバ２における処理遅延とを足し合わせた時間に相当する。
【００３９】
図１０は、セッション要求パケットの入力データレートとの比較に用いられるセッション応答パケットの入力データレートのタイミングを示す図である。同図では、観測周期を単位とした離散時間１ｃから５ｃにおいて、セッション要求パケットの入力データレートが得られている。セッション応答パケットの入力データレートは、一定時間Ｔ＿ＲＴＴを経過した後に、セッション要求パケットの入力データレートと同様の変化を起こす。よって、ＮＷコントローラ６の制御部６３は、セッション要求パケットの入力データレートと、Ｔ＿ＲＴＴだけタイミングが後ろにずれたセッション応答パケットの入力データレートを比較する。
【００４０】
同図に示す例では、Ｔ＿ＲＴＴ＝４ｃである。ＮＷコントローラ６の制御部６３は、離散時間３ｃにおけるセッション応答パケットの入力データレートと、離散時間７ｃ（＝３ｃ＋４ｃ）におけるセッション要求パケットの入力データレートとを比較する。
【００４１】
図１１は、ＮＷコントローラ６がＬ２ＳＷ５へのシェーピング設定を行うシーケンス図である。ここでは、Ｌ２ＮＷ４を構成し、かつ、ＮＷコントローラ６から制御可能なＬ２ＳＷ５の中で、処理能力の一時的な枯渇又はバーストトラヒックが発生しているアプリケーションサーバ２にＬ２ＳＷ＃４が最も近く、次にＬ２ＳＷ＃３が近いとする。
【００４２】
まず、ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃４に対してシェーピング依頼を送信する（ステップＳ１０５）。Ｌ２ＳＷ＃４は、シェーピング依頼を受信すると、自身の空きキューおよびシェーピングリソースを確認する（ステップＳ１１０）。Ｌ２ＳＷ＃４は、確認の結果、シェーピング不可能であると判断すると、ＮＷコントローラ６にシェーピング不可通知を送信する（ステップＳ１１５）。
【００４３】
ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃４からシェーピング不可通知を受信すると、次にＬ２ＳＷ＃３に対してシェーピング依頼を送信する（ステップＳ１２０）。Ｌ２ＳＷ＃３は、ＮＷコントローラ６からのシェーピング依頼を受信すると、自身の空きキューおよびシェーピングリソースを確認する（ステップＳ１２５）。Ｌ２ＳＷ＃３は、確認の結果、シェーピング可能であると判断すると、シェーピング設定を実行し（ステップＳ１３０）、ＮＷコントローラ６に対して、シェーピング設定完了通知を送信する（ステップＳ１３５）。
【００４４】
図１２は、ネットワークシステム１のシェーピング開始処理を示すフロー図である。同図では、アプリケーションサーバ２における処理能力の一時的な枯渇又はバーストトラヒックの検知からシェーピング設定変更までの流れを示している。ＮＷコントローラ６のデータ収集部６２は、各Ｌ２ＳＷ５から定期的に観測周期毎に得られた観測データを受信し、記憶部６１に登録している。ネットワークシステム１は、同図に示す処理を、観測周期と同じ長さの処理周期毎に行う。
【００４５】
まず、ＮＷコントローラ６のシェーピング開始制御部６３１は、変数ｊを１に初期化する。シェーピング開始制御部６３１は、ｊ番目のアプリケーションサーバ２であるアプリサーバ＃ｊについて以下のステップＳ２０５からステップＳ２４０のループ処理Ａを行う。
【００４６】
まず、シェーピング開始制御部６３１は、直近の観測周期の上り観測データからアプリサーバ＃ｊのセッション要求パケットの入力データレートを取得する。シェーピング開始制御部６３１は、取得した入力データレートが閾値αより大きいか否かを判断する（ステップＳ２０５）。例えば、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５の上り観測データそれぞれから得られる入力データレートについて判断を行ってもよく、全て又は複数のＬ２ＳＷ５の上り観測データから得られる入力データレートの合計について判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の上り観測データに基づいて、アプリサーバ＃ｊへの合計の入力データレートを取得し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５の上り観測データの合計から得られる入力データレートを用いる。なお、Ｌ２ＮＷ４それぞれの入力データレートを用いて判断を行う場合、入力データレートの取得元となる上り観測データを生成したＬ２ＳＷ５のアプリケーションサーバ２からのホップ数や、下流のＬ２ＳＷ５や端末３の台数等に応じて、閾値αを異なる値としてもよい。
【００４７】
シェーピング開始制御部６３１は、アプリサーバ＃ｊのセッション要求パケットの入力データレートが閾値α以下であると判断した場合（ステップＳ２０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１、アプリサーバ＃ｊのセッション要求パケットの入力データレートが閾値αよりも大きいと判断した場合（ステップＳ２０５：ＹＥＳ）、ステップＳ２１０の処理を行う。なお、シェーピング開始制御部６３１は、Ｌ２ＮＷ４それぞれの入力データレートについて判断を行う場合、それら全ての入力データレートが閾値α以下である場合にステップＳ２０５においてＮＯと判断し、いずれかの入力データレートが閾値αを超えている場合、ステップＳ２０５においてＹＥＳと判断する。
【００４８】
シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データレートを、直近の観測周期の下り観測データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートを、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り観測データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレートと、セッション要求パケットの入力データレートの比である入力データレート比を計算し、閾値βより大きいか否かを判断する（ステップＳ２１０）。閾値βは、アプリケーションサーバ２が、セッション要求パケットに応じて正常にセッション応答パケットを送信したときの入力データレートの比よりも十分小さな（乖離した）値である。
【００４９】
このとき、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５のそれぞれについて算出した入力データレート比について判断を行ってもよく、全て又は複数のＬ２ＳＷ５についてまとめて算出した入力データレート比について判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の観測データに基づいて、Ｌ２ＮＷ４全体におけるアプリサーバ＃ｊへの入力データレート比を算出し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５の観測データの合計から得られる入力データレート比を用いる。シェーピング開始制御部６３１は、Ｌ２ＳＷ５それぞれについて算出した入力データレート比について判断を行う場合、全てのＬ２ＳＷ５について入力データレート比が閾値βより大きい場合にステップＳ２１０においてＹＥＳと判断し、いずれかのＬ２ＳＷ５の入力データレート比が閾値β以下である場合に、ステップＳ２１０においてＮＯと判断する。なお、入力データレート比が得られたＬ２ＳＷ５のアプリケーションサーバ２からのホップ数や、下流のＬ２ＳＷ５や端末３の台数等に応じて、閾値βを異なる値としてもよい。
【００５０】
シェーピング開始制御部６３１は、入力データレート比が閾値βより大きい判断した場合（ステップＳ２１０：ＹＥＳ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１は、入力データレート比が閾値β以下であると判断した場合（ステップＳ２１０：ＮＯ）、アプリサーバ＃ｊ宛てに送信したセッション要求パケットに対して、正常にセッション応答パケットが送信されておらず、アプリサーバ＃ｊにおいて処理能力の一時的な枯渇又はバーストトラヒックが発生したと判断する（ステップＳ２１５）。処理能力の一時的な枯渇又はバーストトラヒックが発生したと推測される時点は、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期である。
【００５１】
シェーピング開始制御部６３１は、図６に示すホップ数データを参照し、ＮＷコントローラ６から制御可能なＬ２ＳＷ５に対して、アプリサーバ＃ｊからのホップ数が小さい順に番号ｉを付与する。シェーピング開始制御部６３１は、変数ｉを１に初期化し、ステップＳ２２０〜ステップＳ２３０のループ処理Ｂを行う。
【００５２】
シェーピング開始制御部６３１は、ｉ番目のＬ２ＳＷ５であるＬ２ＳＷ＃ｉにシェーピング依頼通知を送信する（ステップＳ２２０）。例えば、シェーピング対象は、アプリサーバ＃ｊ宛てのセッション要求パケットでもよく、アプリサーバ＃ｊ宛ての全てのパケットでもよい。また、シェーピング後のデータレートが、予め取得しておいたアプリサーバ＃ｊが処理可能なデータレートとなるようなシェーピングレートをシェーピング依頼通知で指示してもよい。アプリサーバ＃ｊが処理可能なデータレートは、例えば、全てのＬ２ＳＷ５に共通でもよく、Ｌ２ＳＷ５ごとに決められてもよい。Ｌ２ＳＷ５ごとに処理可能なデータレートが決められる場合、アプリケーションサーバ２からＬ２ＳＷ５までのホップ数や、Ｌ２ＳＷ５の配下のＬ２ＮＷ４又は端末３の台数に応じて決められてもよい。
【００５３】
シェーピング依頼通知を受信したＬ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が可能か否かを判断する（ステップＳ２２５）。Ｌ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が不可と判断した場合（ステップＳ２２５：ＮＯ）、ＮＷコントローラ６にシェーピング不可通知を返送する（ステップＳ２３０）。シェーピング開始制御部６３１は、シェーピング不可通知を受信すると、現在のｉの値に１を加算し、ステップＳ２２０からのループ処理Ｂを繰り返す。
【００５４】
Ｌ２ＳＷ＃ｉの制御部５８は、シェーピングの設定が可能と判断した場合（ステップＳ２２５：ＹＥＳ）、シェーパー５５に対してシェーピングを行うよう制御を行う（ステップＳ２３５）。Ｌ２ＳＷ＃ｉの制御部５８は、シェーピング設定完了通知をＮＷコントローラ６に返送する（ステップＳ２４０）。
【００５５】
ＮＷコントローラ６のシェーピング開始制御部６３１は、Ｌ２ＳＷ＃ｉからシェーピング設定完了通知を受信してループ処理Ｂを終了した後、あるいは、変数ｉの値がＬ２ＳＷ５の台数（又はＮＷコントローラ６から制御可能なＬ２ＳＷ５の台数）であるときのループ処理Ｂを実行した後、現在の変数ｊの値に１を加算してループ処理Ａを繰り返す。シェーピング開始制御部６３１は、変数ｊの値がアプリケーションサーバ２の台数であるときのループ処理Ａを実行した後、図１２の処理を終了する。
【００５６】
なお、上記のステップＳ２１０において、シェーピング開始制御部６３１は、セッション応答パケットの入力データレートと、セッション要求パケットの入力データレートの比を用いて、バーストトラヒックの発生を判断しているが、入力データレートに代えて入力データ量又は入力パケット数を用いることができる。ステップＳ２１０において、シェーピング開始制御部６３１は、観測データから、セッション応答パケットの入力データ量と、セッション要求パケットの入力データ量とを取得し、それらの比と閾値とを比較する。あるいは、シェーピング開始制御部６３１は、観測データから、セッション応答パケットの入力パケット数と、セッション要求パケットの入力パケット数とを取得し、それらの比と閾値とを比較する。なお、入力パケット数を用いる場合、通知部５７は、各観測周期の上り観測データに宛先のアプリケーションサーバ２及びパケットの種類ごとの入力パケット数を設定し、各観測周期の下り観測データに、送信元のアプリケーションサーバ２及びパケットの種別ごとの入力パケット数を設定する。
【００５７】
次に、上記のステップＳ２３５において設定したシェーピングの終了制御について説明する。ＮＷコントローラ６のシェーピング終了制御部６３２は、Ｌ２ＳＷ５が生成した観測データを参照し、アプリサーバ＃ｊ（ｊ＝１，２，…）において処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定された時点からのアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートの積算値と、アプリサーバ＃ｊからのセッション応答パケットの入力データレートの積算値とを取得する。シェーピング終了制御部６３２は、これらの積算値の比較に基づいて、バーストトラヒックの終了を推定する。シェーピング終了制御部６３２は、観測データに基づいてバーストトラヒックが終了したと推定した場合に、アプリサーバ＃ｊ宛ての上りパケットのシェーピングの終了をＬ２ＳＷ５に依頼する。
【００５８】
なお、図９及び図１０に示したように、セッション要求パケットがＬ２ＳＷ＃ｉを通過してアプリサーバ＃ｊに到着し、処理され、セッション応答パケットとして同一のＬ２ＳＷ＃ｉスイッチに戻るまでには一定の時間Ｔ＿ＲＴＴを要する。そこで、シェーピング終了制御部６３２は、セッション応答パケットの積算開始タイミングを、セッション要求パケットの積算開始タイミングよりもＴ＿ＲＴＴだけ経過した時点とする。図１０では、Ｔ＿ＲＴＴ＝４ｃであるため、セッション要求パケットの積算開始タイミングが離散時間３ｃであるときには、セッション要求パケットの積算開始タイミングを離散時間７ｃ（＝３ｃ＋４ｃ）とする。
【００５９】
図１３は、各観測周期におけるネットワークシステム１のシェーピング終了処理を示すフロー図である。同図では、バーストトラヒック終了の検知し、Ｌ２ＳＷ５に設定されているシェーピングレートの設定解除までの流れを示している。ネットワークシステム１は、同図に示す処理を観測周期と同じ長さの処理周期毎に行う。
【００６０】
ＮＷコントローラ６のシェーピング終了制御部６３２は、変数ｉを１に初期化する。さらに、シェーピング終了制御部６３２は、変数ｊの値を１に初期化する。シェーピング終了制御部６３２は、記憶部６１に記憶される観測データから、ｉ番目のＬ２ＳＷ５であるＬ２ＳＷ＃ｉにおけるアプリサーバ＃ｊの観測要求データレート及び観測応答データレートを算出する。観測要求データレートは、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降にＬ２ＳＷ＃ｉにおいて観測されたアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートの積算値である。観測応答データレートは、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点からＴ＿ＲＴＴが経過した以降にＬ２ＳＷ＃ｉにおいて観測されたアプリサーバ＃ｊからのセッション応答パケットの入力データレートの積算値である。シェーピング終了制御部６３２は、観測応答データレートを観測要求データレートにより除算してレートＲを算出する（ステップＳ３０５）。
【００６１】
シェーピング終了制御部６３２は、算出したレートＲが閾値ＴＲよりも大きいか否かを判断する（ステップＳ３１０）。セッション要求パケットとセッション応答パケットのパケットサイズが等しい場合、閾値ＴＲとして１に十分近く１よりも小さい値、例えば、て０．７５を用いる。セッション要求パケットとセッション応答パケットのサイズ比が異なる場合は、サイズ比に合わせて閾値ＴＲを変更する。例えば、セッション要求パケットのサイズ：セッション応答パケットのサイズ＝１０：９の場合は、Ｒ＝０．９のときに２種類のパケットの入力レートは等しい。この場合、閾値ＴＲを０．９に十分近く、０．９よりも小さい値とする。
【００６２】
シェーピング終了制御部６３２は、レートＲが閾値ＴＲ以下であると判断した場合（ステップＳ３１０：ＮＯ）、ｊの値に１を加算してステップＳ３０５からの処理を繰り返す。シェーピング終了制御部６３２は、レートＲが閾値ＴＲを超えると判断した場合（ステップＳ３０５：ＹＥＳ）、アプリサーバ＃ｊにおける処理能力の一時的な枯渇又はバーストトラヒックが終了したと判断する（ステップＳ３１５）。シェーピング終了制御部６３２は、処理能力の一時的な枯渇又はバーストトラヒックが発生する前のシェーピングレートを設定するためのシェーピングレート変更指示を全てのＬ２ＳＷ５、又は、Ｌ２ＳＷ＃ｉに送信する（ステップＳ３２０）。シェーピングレート変更指示を受信したＬ２ＳＷ５の制御部５８は、シェーピングレートの変更をシェーパー５５に設定する。シェーピング終了制御部６３２は、ｊの値に１を加算してステップＳ３０５からの処理を繰り返す。なお、シェーピングレートを段階的に増加させ、元に戻してもよい。
【００６３】
シェーピング終了制御部６３２は、変数ｉの値がＮＷコントローラ６から制御可能なＬ２ＳＷ５の台数であるときのステップＳ３０５〜ステップＳ３２０までの処理を終えると、現在の変数ｊの値に１を加算した後、変数ｉを初期値から順に１ずつ増加させ、各ｉの値についてステップＳ３０５〜ステップＳ３２０の処理を繰り返す。シェーピング開始制御部６３１は、変数ｊの値がアプリケーションサーバ２の台数に達すると、処理を終了する。
【００６４】
なお、入力データレートに代えて入力データ量又は入力パケット数を用いて上記のステップＳ３０５及びステップＳ３１０の処理を行ってもよい。入力データ量データを用いる場合、上記におけるレートＲに代えて、以下の指標Ｒ’を用いて、閾値と比較する。
【００６５】
Ｒ’＝セッション応答パケットデータ量積算値／セッション要求パケットデータ量積算値
【００６６】
上記におけるセッション要求パケットデータ量積算値は、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降のセッション要求パケットの入力データ量の積算値である。また、セッション応答パケットデータ量積算値は、その推定される時点からＴ＿ＲＴＴ経過した以降のセッション応答パケットの入力データ量の積算値である。
【００６７】
また、入力パケット数を用いる場合、上記におけるレートＲに代えて、以下の指標Ｒ”を用いて、閾値と比較する。
【００６８】
Ｒ”＝セッション応答パケット数積算値／セッション要求パケット数積算値
【００６９】
上記におけるセッション要求パケット数積算値は、処理能力の一時的な枯渇又はバーストトラヒックが発生したと推定される時点以降のセッション要求パケットの入力パケット数の積算値である。また、セッション応答パケット数積算値は、その推定される時点からＴ＿ＲＴＴ経過した以降のセッション応答パケットの入力パケット数の積算値である。
【００７０】
本実施形態によれば、アプリケーションサーバ２における処理能力が一時的に枯渇した、又は、バーストトラヒックが発生したことを検出し、Ｌ２ＮＷ４全体におけるセッション応答パケットのトラヒックを低減することができる。また、アプリケーションサーバ２に問い合わせることなく、アプリケーションサーバ２における処理能力が回復した、又は、バーストトラヒックの発生が終了したことを検出し、Ｌ２ＳＷ５において行っていたシェーピングを終了させることができる。
【００７１】
（第２の実施形態）
第１の実施形態においては、Ｌ２ＳＷ５におけるセッション応答パケットとセッション要求パケットの入力データレートの比、入力データ量の比、または、入力パケット数の比に基づいてバーストトラヒックの発生又はアプリケーションサーバ２における処理能力の一時的な枯渇を判断していた。本実施形態では、第１の実施形態の入力データレート、入力データ量、または、入力パケット数に代えて、過去の観測周期からの入力データレートの増分、入力データ量の増分、入力パケット数の増分を用いる。以下では、入力データレートの増分を用いる場合を例として、第１の実施形態との差分を中心に説明する。
【００７２】
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。
【００７３】
ＮＷコントローラ６のデータ収集部６２は、第１の実施形態と同様に、各Ｌ２ＮＷ４から図７に示す上り観測データ及び図８に示す下り観測データを含む観測周期毎の観測データを周期的に受信し、記憶部６１に書き込む。さらに、データ収集部６２は、収集した観測データと、その観測データよりも１観測周期前の観測データとを用いて、各Ｌ２ＮＷ４におけるアプリケーションサーバ２及びパケット種別ごとの上りパケット及び下りパケットの入力データレート増分を算出し、記憶部６１に登録する。
【００７４】
図１４は、前周期上り観測データの例を示す図である。前周期上り観測データは、図７に示す上り観測データと同じＬ２ＮＷ４における１観測周期前の上り観測データから得られる。同図に示す前周期上り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、Ｌ２ＳＷ５が観測（計測）した上りパケットの前回入力データレート及び前回入力データ量を示す。前回入力データレートは、１観測周期前の上りパケットの入力データレートであり、前回入力データ量は、１観測周期前の入力データ量である。パケット種別は、セッション要求パケットであるか否かにより表される。
【００７５】
図１５は、上り増分データの例を示す図である。上り増分データは、アプリケーションサーバ２及びパケット種別毎の上りパケットの入力データレートの増分を示す。入力データレートの増分は、図７に示す上り観測データが示す入力データレートから、図１４に示す前回上り観測データが示す前回入力データレートを減算して得られる。
【００７６】
図１６は、前周期下り観測データの例を示す図である。前周期下り観測データは、図８に示す下り観測データと同じＬ２ＮＷ４における１観測周期前の下り観測データから得られる。同図に示す前周期下り観測データは、アプリケーションサーバ２の識別情報及びパケット種別ごとに、Ｌ２ＳＷ５が観測（計測）した下りパケットの前回入力データレートを示す。前回入力データレートは、１観測周期前の下りパケットの入力データレートである。パケット種別は、セッション応答パケットであるか否かにより表される。
【００７７】
図１７は、下り増分データの例を示す図である。下り増分データは、アプリケーションサーバ２及びパケット種別毎の下りパケットの入力データレートの増分を示す。入力データレートの増分は、図８に示す下り観測データが示す入力データレートから、図１６に示す前回下り観測データが示す前回入力データレートを減算して得られる。
【００７８】
図１８は、セッション要求パケットの入力データレート増分との比較に用いられるセッション応答パケットの入力データレート増分のタイミングを示す図である。同図では、観測周期を単位とした離散時間１ｃから５ｃにおいて、セッション要求パケットの入力データレート増分が得られている。セッション応答パケットの入力データレートは、図１０と同様に、一定時間Ｔ＿ＲＴＴを経過した後に、セッション要求パケットの入力データレートと同様の変化を起こす。そこで、ＮＷコントローラ６のシェーピング開始制御部６３１は、セッション要求パケットの入力データレート増分と、Ｔ＿ＲＴＴだけタイミングが後にずれたセッション応答パケットの入力データレート増分とを比較する。
【００７９】
同図に示す例では、Ｔ＿ＲＴＴ＝４ｃである。ＮＷコントローラ６のシェーピング開始制御部６３１は、離散時間１ｃにおけるセッション応答パケットの入力データレート増分と、離散時間５ｃ（＝１ｃ＋４ｃ）におけるセッション要求パケットの入力データレート増分とを比較する。
【００８０】
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ２１０の処理を除き、図１２に示す第１の実施形態と同様である。すなわち、ステップＳ２１０において、シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データレート増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレート増分と、セッション要求パケットの入力データレート増分の比である入力データレート増分比を計算し、閾値よりも大きいか否かを判断する。閾値は、１よりも十分小さい値を用いる。シェーピング開始制御部６３１は、入力データレート増分比が閾値よりも大きいと判断した場合（ステップＳ２１０：ＹＥＳ）、変数ｊの値に１を加算して、再びステップＳ２０５からの処理を行う。一方、シェーピング開始制御部６３１は、入力データレート増分比が閾値以下であると判断した場合（ステップＳ２１０：ＮＯ）、アプリサーバ＃ｊにおいて処理能力の一時的な枯渇又はバーストトラヒックが発生したと判断する（ステップＳ２１５）。
【００８１】
なお、入力データレートの増分に代えて、入力データ量の増分又は入力パケット数の増分を用いることができる。この場合、上り増分データは、アプリケーションサーバ２及びパケット種別毎の上りパケットの入力データ量の増分又は入力パケット数の増分を示す。上りパケットの入力データ量の増分又は入力パケット数の増分は、上り観測データが示す入力データ量又は入力パケット数から、当該上り観測データよりも１観測周期前の上り観測データが示す入力データ量又は入力パケット数を減算して得られる。また、下り増分データは、アプリケーションサーバ２及びパケット種別毎の下りパケットの入力データ量の増分又は入力パケット数の増分を示す。下りパケットの入力データ量の増分又は入力パケット数の増分は、下り観測データが示す入力データ量又は入力パケット数から、当該下り観測データよりも１観測周期前の下り観測データが示す入力データ量又は入力パケット数を減算して得られる。
【００８２】
そして、ステップＳ２１０において、シェーピング開始制御部６３１は、アプリサーバ＃ｊからのセッション応答パケットの入力データ量の増分又は入力パケット数の増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データ量の増分又は入力パケット数の増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データ量の増分又は入力パケット数の増分と、セッション要求パケットの入力データ量の増分又は入力パケット数の増分の比を計算し、閾値よりも大きいか否かを判断する。
【００８３】
本実施形態によるネットワークシステム１のシェーピング終了処理は、ステップＳ３０５及びステップＳ３１０の処理を除き、図１３に示す第１の実施形態と同様である。すなわち、シェーピング終了制御部６３２は、Ｌ２ＳＷ＃ｉにおけるアプリサーバ＃ｊからのセッション応答パケットの入力データレート増分を、現在の処理周期の直近の観測周期の下り増分データから取得する。さらに、シェーピング開始制御部６３１は、Ｌ２ＳＷ＃ｉにおけるアプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期からＴ＿ＲＴＴだけ遡った観測周期の上り増分データから取得する。シェーピング開始制御部６３１は、セッション応答パケットの入力データレート増分と、セッション要求パケットの入力データレート増分の比である入力データレート増分比を計算する（ステップＳ３０５）。シェーピング終了制御部６３２は、算出した入力データレート増分比が閾値よりも大きいか否かを判定する（ステップＳ３１０）。閾値には、１に十分近く１よりも小さい値、例えば、０．７５を用いる。シェーピング終了制御部６３２は、入力データレート増分比が閾値以下であると判断した場合（ステップＳ３１０：ＮＯ）、ｉの値に１を加算してステップＳ３０５からの処理を繰り返し、入力データレート増分比が閾値よりも大きいと判断した場合（ステップＳ３１０：ＹＥＳ）、ステップＳ３１５の処理を行う。
【００８４】
本実施形態によれば、第１の実施形態と同様に、アプリケーションサーバ２における処理能力が一時的に枯渇した、又は、バーストトラヒックが発生したことを検出し、Ｌ２ＮＷ４全体におけるセッション応答パケットのトラヒックを低減することができる。
【００８５】
（第３の実施形態）
本実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートが、アプリケーションサーバ２において処理可能な入力データレートを超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第１の実施形態との差分を中心に説明する。
【００８６】
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。ただし、ＮＷコントローラ６の６１は、各アプリケーションサーバ２の処理能力データをさらに記憶する。
【００８７】
図１９は、処理能力データの例を示す図である。同図に示す処理能力データは、各アプリケーションサーバ２の識別情報及びパケット種別ごとに、アプリケーションサーバ２が処理可能なデータ量、データレート及びデータレート増分を示す。パケット種別は、セッション要求パケットであるか否かにより示される。なお、本実施形態においては、アプリケーションサーバ２が処理可能なデータレート及びデータレート増分が設定されていなくてもよい。
【００８８】
図２０は、本実施形態のネットワークシステム１におけるシェーピング開始処理を示すフロー図である。同図において、図１２に示す第１の実施形態のフロー図と同一の処理には同一の符号を付し、説明を省略する。
【００８９】
まず、シェーピング開始制御部６３１は、変数ｊを１に初期化する。シェーピング開始制御部６３１は、ｊ番目のアプリケーションサーバ２であるアプリサーバ＃ｊについてス以下のステップＳ４０５からステップＳ２４０のループ処理Ａ’を行う。
【００９０】
シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレートを、直近の観測周期の上り観測データから取得し、観測要求データレートとする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのデータ量を取得し、登録要求データレートとする。シェーピング開始制御部６３１は、観測要求データレートが、登録要求データレート×ｋ（ｋは係数）を超えているか否かを判定する（ステップＳ４０５）。
【００９１】
このとき、シェーピング開始制御部６３１は、Ｌ２ＮＷ４を構成する全ての又は一部のＬ２ＳＷ５のそれぞれについて取得した観測要求データレートについて判断を行ってもよく、全て又は複数のＬ２ＳＷ５についてまとめて算出した観測要求データレートについて判断を行ってもよい。例えば、シェーピング開始制御部６３１は、１又は複数台のＬ２ＳＷ５の観測データに基づいて、Ｌ２ＮＷ４全体におけるアプリサーバ＃ｊへの観測要求データレートを算出し、判断に用いてもよい。一例として、シェーピング開始制御部６３１は、アプリサーバ＃ｊから１ホップだけ離れたＬ２ＳＷ５についてまとめて算出した観測要求データレートを用いてもよい。なお、シェーピング開始制御部６３１は、Ｌ２ＳＷ５のそれぞれについて算出した観測要求データレートについて判断を行う場合、全てのＬ２ＳＷ５について登録要求データレート×ｋ以下である場合にステップＳ４０５においてＮＯと判断し、いずれかのＬ２ＳＷ５の観測要求データレートが登録要求データレート×ｋを超えている場合に、ステップＳ４０５においてＹＥＳと判断する。係数ｋの値は、Ｌ２ＳＷ５で共通であってもよく、アプリケーションサーバ２からのホップ数や下流のＬ２ＳＷ５又は端末３の台数等に応じてＬ２ＳＷ５ごとに異なっていてもよい。また、ホップ数や下流のＬ２ＳＷ５又は端末３の台数等に応じた処理能力データを記憶部６１に保持しておき、観測要求データレートが得られたＬ２ＳＷ５に対応した処理能力データから登録要求データレートを読み出してもよい。
【００９２】
シェーピング開始制御部６３１は、観測要求データレートが、登録要求データレート×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測要求データレートが登録要求データレート×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。これにより、アプリサーバ＃ｊになるべく近いＬ２ＮＷ４にシェーピングを設定してバーストトラヒックが起きたフローのシェーピングレートを減少させ、アプリサーバ＃ｊに同時に到着するセッション要求パケットを抑制する。
【００９３】
例えば、シェーピング開始制御部６３１は、Ｌ２ＳＷ５におけるアプリサーバ＃ｊ宛てのセッション要求パケット又は全パケットのデータレートを、アプリサーバ＃ｊが処理可能な入力データレートまで削減するようＬ２ＳＷ５に指示する。アプリサーバ＃ｊが処理可能な入力データレートは、例えば、全てのＬ２ＳＷ５に共通でもよく、Ｌ２ＳＷ５ごとに決められてもよい。また、処理可能な入力データレートは、アプリサーバ＃ｊの登録要求データレートでもよく、登録要求データレートに対して、アプリケーションサーバ２からＬ２ＳＷ５までのホップ数や、Ｌ２ＳＷ５の配下のＬ２ＮＷ４又は端末３に応じた係数を乗算した値でもよい。
【００９４】
本実施形態によれば、予めアプリケーションサーバ２から処理可能なデータレートを取得しておくことで、アプリケーションサーバ２宛てのバーストトラヒックの発生を判断し、トラヒック量を低減することが可能である。
【００９５】
（第４の実施形態）
第３の実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートが、アプリケーションサーバ２において処理可能なデータレートを超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。本実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データ量が、アプリケーションサーバ２において処理可能なデータ量を超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第３の実施形態との差分を中心に説明する。
【００９６】
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。ＮＷコントローラ６の記憶部６１は、図１９に示す処理能力データを記憶する。ただし、処理能力データには、アプリケーションサーバ２が処理可能なデータレート及びデータレート増分が設定されていなくてもよい。
【００９７】
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ４０５の処理を除き、図２０に示す第３の実施形態と同様である。すなわち、ステップＳ４０５において、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データ量を、直近の観測周期の上り観測データから取得し、観測要求データ量とする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのデータ量を取得し、登録要求データ量とする。シェーピング開始制御部６３１は、観測要求データ量が、登録要求データ量×ｋ（ｋは係数）を超えているか否かを判定する。シェーピング開始制御部６３１は、観測要求データ量が、登録要求データ量×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測要求データ量が登録要求データ量×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。
【００９８】
（第５の実施形態）
第５の実施形態では、Ｌ２ＳＷ５におけるセッション要求パケットの入力データレートの増分が、アプリケーションサーバ２において処理可能なデータレートの増分を超過した場合、セッション要求パケットのバーストトラヒックが発生したと判断する。以下では、第３の実施形態との差分を中心に説明する。
【００９９】
本実施形態のネットワークシステムは、図１に示す第１の実施形態のネットワークシステム１と同様である。また、本実施形態のＬ２ＳＷ５及びＮＷコントローラ６の構成はそれぞれ、図４に示すＬ２ＳＷ５及びＮＷコントローラ６の構成と同様である。
【０１００】
ＮＷコントローラ６のデータ収集部６２は、第１の実施形態と同様に、各Ｌ２ＮＷ４から図７に示す上り観測データ及び図８に示す下り観測データを含む観測周期毎の観測データを周期的に受信し、記憶部６１に書き込む。さらに、データ収集部６２は、収集した上り観測データと、その観測データよりも１観測周期前の上り観測データとを用いて、各Ｌ２ＮＷ４におけるアプリケーションサーバ２及びパケット種別ごとの上りパケットの入力データレート増分を算出し、記憶部６１に登録する。すなわち、データ収集部６２は、観測データを記憶部６１に記憶すると、１観測周期前の上り観測データを図１４に示す前周期上り観測データとして記憶部６１に書き込み、上り観測データ及び前周期上り観測データを用いて、図１５に示す上り増分データを生成して記憶部６１に書き込む。
【０１０１】
本実施形態によるネットワークシステム１のシェーピング開始処理は、ステップＳ４０５の処理を除き、図２０に示す第３の実施形態と同様である。すなわち、ステップＳ４０５において、シェーピング開始制御部６３１は、アプリサーバ＃ｊ宛てのセッション要求パケットの入力データレート増分を、直近の観測周期の上り増分データから取得し、観測増分データとする。さらに、シェーピング開始制御部６３１は、処理能力データから、アプリサーバ＃ｊが処理可能なセッション要求パケットのレート増分を取得し、登録増分データとする。シェーピング開始制御部６３１は、観測増分データが、登録増分データ×ｋ（ｋは係数）を超えているか否かを判定する。シェーピング開始制御部６３１は、観測増分データが、登録増分データ×ｋ以下であると判断した場合（ステップＳ４０５：ＮＯ）、変数ｊの値に１を加算して、再びステップＳ４０５からの処理を行う。一方、シェーピング開始制御部６３１は、観測増分データが登録増分データ×ｋよりも大きいと判断した場合（ステップＳ４０５：ＹＥＳ）、アプリサーバ＃ｊ宛てのバーストトラヒックが発生したと判断し（ステップＳ４１０）、第１の実施形態と同様にループ処理Ｂを行う。
【０１０２】
本実施形態によるネットワークシステム１のシェーピング終了処理は、第２の実施形態と同様であるが、第１の実施形態と同様であってもよい。
【０１０３】
なお、ＮＷコントローラ６は、バスで接続されたCentral Processing Unit（ＣＰＵ）やメモリや補助記憶装置などを備え、プログラムを実行することによって上記の機能を実現するようにしてもよい。なお、ＮＷコントローラ６の各機能の全て又は一部は、Application Specific Integrated Circuit（ＡＳＩＣ）やProgrammable Logic Device（ＰＬＤ）やField Programmable Gate Array（ＦＰＧＡ）等のハードウェアを用いて実現されても良い。プログラムは、コンピュータ読み取り可能な記録媒体に記録されても良い。コンピュータ読み取り可能な記録媒体とは、例えばフレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置である。プログラムは、電気通信回線を介して送信されても良い。
【０１０４】
以上説明した実施形態によれば、ネットワークシステムは、１以上の中継装置からなる中継ネットワークにより、第一通信装置と第二通信装置との間のパケットを中継する。例えば、中継装置はＬ２ＳＷ５であり、中継ネットワークはＬ２ＮＷ４であり、第一通信装置は端末３であり、第二通信装置はアプリケーションサーバ２である。ネットワーク制御装置は、データ収集部と、制御部とを備える。例えば、ネットワーク制御装置は、ＮＷコントローラ６である。
【０１０５】
データ収集部は、中継装置から、当該中継装置へ入力されたパケットを観測して得られた、第一通信装置から第二通信装置宛ての処理要求パケットのトラヒック量を示す上り観測データと、第二通信装置が処理要求パケットに対応して第一通信装置宛てに送信した応答パケットのトラヒック量を示す下り観測データとを収集する。例えば、処理要求パケットは、セッションの開始を要求するセッション要求パケットであり、応答パケットは、セッション要求パケットへの応答を示すセッション応答パケットである。また、例えば、トラヒック量は、中継装置への入力データレート、入力データ量又は入力パケット数である。
【０１０６】
制御部は、上り観測データが示すトラヒック量と下り観測データが示すトラヒック量との比、又は、上り観測データから得られるトラヒック量の増分と下り観測データから得られるトラヒック量の増分との比に基づいて、中継ネットワークを構成する中継装置に対して第二通信装置宛てのパケットを通過させる速さであるシェーピングレートを変更する。例えば、制御部は、上記の比に基づいて、第二通信装置宛ての処理要求パケットのバーストトラヒックの発生又は終了を検出し、発生を検出したときにはシェーピングレートを減少させ、終了を検出したときにはシェーピングレートを増加させるよう制御する。例えば、制御部は、バーストトラヒックの終了を検出したときには、バーストトラヒックが発生する前に設定してあったシェーピングレートに戻すように制御する。
【０１０７】
また、制御部は、上り観測データが示すトラヒック量と、第二通信装置が処理可能な処理要求パケットのトラヒック量との比較に基づいて、又は、上り観測データから得られるトラヒック量の増分と、第二通信装置が処理可能な処理要求パケットのトラヒック量の増分との比較に基づいて、第二通信装置宛ての処理要求パケットのバーストトラヒックの発生を検出してもよい。
【０１０８】
また、制御部は、シェーピングレートの変更が可能である旨の通知を受信するまで、中継ネットワークを構成する中継装置のうち第二通信装置に近い中継装置から順にシェーピングレートの変更依頼を送信してもよい。
【０１０９】
以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。
【符号の説明】
【０１１０】
１、１ｂ…ネットワークシステム，  ２−１，２−２…アプリケーションサーバ，  ３…端末，  ４、４ａ、４ｂ…Ｌ２ＮＷ，  ５…Ｌ２ＳＷ，  ６…ＮＷコントローラ，  ７…Ｌ３ネットワーク，  ５１…第１ポート，  ５２…マッチング部，  ５３…カウンタ部，  ５４…キュー，  ５５…シェーパー，  ５６…第２ポート，  ５７…通知部，  ５８…制御部，  ６１…記憶部，  ６２…データ収集部，  ６３…制御部，  ６３１…シェーピング開始制御部，  ６３２…シェーピング終了制御部
【図１】
2020017806.tif 000003
【図２】
2020017806.tif 000004
【図３】
2020017806.tif 000005
【図４】
2020017806.tif 000006
【図５】
2020017806.tif 000007
【図６】
2020017806.tif 000008
【図７】
2020017806.tif 000009
【図８】
2020017806.tif 000010
【図９】
2020017806.tif 000011
【図１０】
2020017806.tif 000012
【図１１】
2020017806.tif 000013
【図１２】
2020017806.tif 000014
【図１３】
2020017806.tif 000015
【図１４】
2020017806.tif 000016
【図１５】
2020017806.tif 000017
【図１６】
2020017806.tif 000018
【図１７】
2020017806.tif 000019
【図１８】
2020017806.tif 000020
【図１９】
2020017806.tif 000021
【図２０】
2020017806.tif 000022
【図２１】
2020017806.tif 000023
【図２２】
2020017806.tif 000024