(57)【特許請求の範囲】
【請求項１】
ネットワーク管理者のネットワーク管理ツールによって実行され、
生成段階として、テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成し、
テスト段階として、テストパケットをテストを行いたいパスが通過する交換機に送信し、パステストを行い、
報告段階として、データフローが通過する実際のパスとパス状態を報告する、ことを主に含み、
テスト段階が、テストパケットをテストを行いたいパス始点に位置する交換機に送信し、交換機が直ちに行う報告、テストを行いたいパス終点に位置する交換機による報告済かの判断と時間制限に到達済かの判断を待機後に受信し、終点交換機による報告済かの判断が主に終点交換機による報告済か否かの判断であり、報告済ならば報告段階に入り、未報告ならば時間制限に到達済の判断に入る手順であり、時間制限に到達済かの判断の手順が主にテストの時間制限が到達済か否かの判断であり、到達済ならば報告段階に入り、未到達ならば交換機が直ちに報告するのを待機後に受信するに戻る手順を含み、
実際のパケットをシミュレーションしたテストパケットを生成することについて、主にテストパケットのpayloadに専用のキーワードを記入することで、テストパケットが同じheaderを有する他のパケットと区別できるものである、
集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項２】
テストを行いたいデータフロー情報に従い実際のパケットをシミュレーションしたテストパケットを生成することについて、テストを行いたいデータフロー情報に従い、テストパケットのheaderを生成することで、テストパケットがテストを行いたいデータフローのパケットと同様のルーティングアクションを備える状態を確保するものである、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項３】
テストを行いたいデータフロー情報が送信元MAC、宛先MAC、送信元IP又は宛先IPのパケットの識別用に使える情報を含む、
請求項1又は2に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項４】
テストパケットをテストを行いたいパス始点に位置する交換機に送信することについて、主に始点の交換機に準備段階で生成したテストパケットを送信する、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項５】
交換機が直ちに報告するのを待機後に受信することについて、主に終点の交換機が報告するテストパケットを待機後に受信するものである、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【請求項６】
報告段階が、ネットワーク管理者にテスト段階時にネットワークエレメントが報告した状況に従い集合させたデータフローの実際のパスとパス状態を報告するものである、
請求項1に記載の集中式コントロールプレーンに基づくパス状態の報告演算方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は1種のパス状態の報告演算方法に関わる。本発明は特に1種の費用対効果の考えに合致し、他のネットワーク管理アプリケーションソフトとネットワークエレメントとの互換性を重視しており、他のアプリケーションソフトに影響を及ぼさないことを前提にしてそれと結合し、更に完備されたテストツールを構成すること、又はネットワーク自己最適化に使うことができ、なおかつ集中式のコントロールプレーンによるパス状態の報告演算メカニズムを導入し、データフローが通過する実際のパスを追跡し、ネットワーク管理者とネットワーク管理アプリケーションソフトに更に効率的に障害の分析と排除能力を提供し、効果的にCAPEX(Capital Expenditure 資本的支出)とOPEX(Operating Expenditure 運営費)が減らせる集中式コントロールプレーンに基づくパス状態の報告演算方法を指す。
【背景技術】
【０００２】
従来のネットワークでは、交換機とルータは、パケットの転送が必要なほかにも、ネットワークトポロジーも理解し、データフローのパケットを宛先に伝達するのに通過が必要なパスを決めなければならない。図1の従来型ネットワーク構成図が示すように、ルーティング・ルールの決定を受け持つコントロールプレーン11は各交換機とルータ内に分散しており、ネットワーク管理者13がルーティング・ルールを自ら定める必要がある場合には、各ネットワークエレメント内に接続して個別に設定しなければならない。
【０００３】
加えて、従来型ネットワークの各ネットワークエレメントは、ネットワークトポロジーなどの必要な情報を理解し、リンクレイヤ検出プロトコルLink Layer Discovery Protocol、LLDP）パケットのように互いに各種のメッセージを交換しなければならない。そしてそれぞれが認識したネットワーク情報の交換を通じて、互いに同期でネットワークトポロジーと状態を認識してから、事前に定義済のネットワーク・プロトコル又はルーティング・ルールに従い、ネットワークエレメントそれぞれが、受信したパケットの転送方法を決める。
【０００４】
従来型ネットワークの問題は、次のものを含むがこれらに限定されない。
【０００５】
1. コントロールプレーンが、ハードウェア資源の劣悪な交換機とルータ内に分散され、ネットワークの機能と弾力性を制限してしまう。
【０００６】
2. 膨大な数量のメッセージを交換にすることで、従来型ネットワークの運行効率が落ちてしまう。
【０００７】
3. 各ネットワークエレメントそれぞれが転送アクションの特性を決めるため、ネットワーク管理者は効果的にネットワーク状態を検知しデバッグを行うが難しくなる。
【０００８】
従来型ネットワークは、その分散型のコントロールプレーンが原因となり、集中管理のメカニズムが不十分になり、効果的なネットワーク管理ツールをネットワーク管理者13に供給して、ネットワーク情報を追跡してのデバッグを行わせることができない。ネットワークに問題が現れた場合には又はメンテナンス・操作によりネットワーク情報を手に入れるのが必要になった場合には、図2の従来型ネットワークデバッグ方法の表示図が示すように、ネットワーク管理者13は自発的に各交換機又はルータのログ21を手に入れて分析する、或いはリモートホスト又はルータが返答したreply 22パケットにより間接的にネットワーク情報を手に入れるしかなくなるのである。
【０００９】
ネットワークの規模がある程度を超えた場合には、交換機のログ21数量は分析が難しくなり、なおかつネットワーク管理者13は直ちには必要なネットワーク情報が得られなくなる。加えて、ネットワーク管理者13がパケットのパスが確定できなくなるため、あらゆる交換機とルータのログ21を分析するしかなくなってしまう。その一方で、リモートホスト又はルータを通じて返送してきたreply 22パケットが間接的に手に入れられる情報はタイプが限られ、メンテナンス・操作の効果的な根拠とするのは難しい。ネットワーク状況によりエンドツーエンドのreply 22パケットが回収できない場合には、この方法では必要なパスとネットワーク情報が取得できなくなってしまう。
【００１０】
従来型ネットワークで最も有名なネットワークデバッガはpingとtracerouteを含む。Pingの作動原理は、宛先ホストにICMP echo要求を送信し、受信した応答パケットに従いパケットのロス率と往復時間を計算するものである。Pingの欠点は手に入るネットワーク情報が比較的少なく、その結果だけに基づきネットワークデバッグを行うのが比較的難しいことである。Tracerouteでは、パケットがIPネットワークで通過するルータのリストを手に入れることができる。その作動原理は、ネットワークに対して順番に異なる生存時間(Time to Live, TTL)値を有するICMP要求パケットを送信し、回収されたICMP時間超過パケットによりパスにある各ルータの情報を手に入れることである。Tracerouteの欠点はルータの情報しか手に入らず、交換機とリンクの状態など、パスにある完全な情報が手に入らないことである。加えて、tracerouteの手法ではネットワークに対して比較的多くのパケットを生み出してしまい、パスに合計n個のルータがある場合には、tracerouteはパスにあるルータに合計O(n2)回の転送アクションを行ってしまうことである。
【００１１】
2014年、IBMはソフトウェア・デファインド・ネットワーキング (Software-Defined Networking、SDN)アーキテクチャに基づいて実装したSDN tracerouteを発表した。SDNアーキテクチャは交換機のコントロールプレーンとデータプレーンを分離させて、ネットワークの管理者がSDNネットワークにある交換機のフローテーブル (Flow table)と転送アクションが制御できるようになった。SDN tracerouteはテスト対象となる始点交換機にテストパケットを送信してから、SDN交換機のプログラマブルという特性を通じて、テストパケットがリンクを1段通り過ぎるごとに、1つをコピーしてSDNコントローラに応答して状態の報告を行う。こうしてパケットがネットワークで通過する完全なパス情報を確認するのである。
【００１２】
しかしながら、仮にSDN tracerouteがパケットheaderの一定のフィールドをテストパケットの応答用として留めておける一方で、ネットワークにあるあらゆるコンポーネントとネットワーク管理アプリケーションソフトが当該フィールドを使うのを禁止したとしたら、このような手法は現実にそぐわなくなる。SDN tracerouteの開発者又はその権限要求が利用できるあらゆるアプリケーションソフトの開発者は共にこの規範を遵守しなければならないものの、それでも制御するネットワークの自由度が下がることになり、いつの間にか他のSDNアプリケーションソフトの機能を制限してしまう。加えて、パケットheaderで使用できるビット数が限られることで、複数のテストパケットが同じラベルに対応してしまう恐れがある。テストパケットが他のアプリケーションソフトにより冗長なバックアップをコピーされ、これをネットワーク内に送信された場合には、SDN tracerouteはパスが正確に測定できなくなる恐れがある。
【００１３】
2014年2月1日に公開された我が国特許番号第201406114号「ネットワークパス供給用のセッション情報変換」には、1種のシステムと方法が提起されている。それはサーバと互いに連携するセッションに対応するセッション情報(SESSION INFORMATION) を受信し、セッション情報をトポロジーレイアウトパラメータとデータパラメータを含む変換済セッション情報に変換する。当該変換済セッション情報はコントローラに対し、当該変換済セッション情報によりネットワークパスを供給するよう導くものである。そして当該ネットワークパスは当該トポロジーレイアウトパラメータとデータパラメータに従わせるものである。本発明で示す、テスト対象となるデータフローをシミュレーションしたテストパケットを送信してから、ネットワークエレメントがテストパケットを受信した時に返送してきたパス状態の報告を1つ1つ回収することで、データフローが通過する実際のパスが正確に追跡できる演算方法とは異なっている。
【００１４】
2014年8月20日に公開されたCN103997432号Measuring system and method for supporting analysis of OpenFlow application performanceには、1種の定量分析OpenFlowアプリケーションパフォーマンスを支援する測定システムと方法が提起されている。それはOpenFlowネットワークとの測定サーバに基づく。上記のOpenFlowネットワークはコントローラと個別にコントローラと接続するn台の交換機を含む。n台の交換機はコントローラのOpenFlowによる制御を受け、コントローラとn個の交換機がローカルログ機能とクロック同期機能を拡充してから、測定対象となる物理サーバを測定する集中制御となる。その特徴は、集中式パフォーマンス・ボトルネックがないこと、測定自体によるネットワークアプリケーションへの干渉が少ないこと、データプレーンとコントロールプレーンの情報が全面的に取得できること、コントロールプレーンとデータプレーンの間の相互関係が得られることを含む。本件特許のような集中式コントロールプレーンに基づくパス状態の報告演算方法ではなく、データフローが通過する実際のパス状態を追跡し、ネットワーク管理者とそのネットワーク管理アプリケーションソフトが更に効率的に故障を分析・排除するのを補佐できるものではない。
【００１５】
本発明の1種の集中式コントロールプレーンに基づくパス状態の報告演算方法では、データフローが通過する実際のパス状態が追跡できる。pingに比べて、本発明ではより多くのネットワーク情報がネットワーク管理者に報告できる。tracerouteに比べて、本発明では比較的少ない通信量で、制御するネットワークにある指定したデータフローが通過する実際のパスを探し出し、検知動作がネットワークに及ぼす負担を減らす。SDN tracerouteに比べて、本発明ではパケットのpayload内容を使ってテストパケットの判別の根拠にするため、他のアプリケーションソフトによるパケットheaderの使用と修正を制限せず、他のネットワーク管理アプリケーションソフトと高い互換性があることを前提にして、正確なテスト結果が得られる。
【００１６】
本件特許発明者は前述のシステムと方法の不備を考慮し、直ちに新発明を構想し、長期にわたる苦心と研鑽を重ねてから、ついに研究開発を行い本案件である1種の集中式コントロールプレーンに基づくパス状態の報告演算方法の完成に成功した。
【発明の概要】
【発明が解決しようとする課題】
【００１７】
本発明では1種の集中式コントロールプレーンに基づくパス状態の報告演算方法を提供し、データフローが通過する実際のパス状態が追跡でき、ネットワーク管理者とそのネットワーク管理アプリケーションソフトが更に効率的に故障の分析と排除を行うのを補佐する。本発明の設計では、他のネットワーク管理アプリケーションソフトとネットワークエレメントとの互換性を重視し、テストパケットの判別情報をpayload内に記入することを通じて、これによりパケットheaderの使用と修正が制限を受けないことを前提にして、正確なテスト結果が得られる。
【００１８】
本発明の1種の集中式コントロールプレーンに基づくパス状態の報告演算方法では、テスト対象となるデータフローをシミュレーションするテストパケットの送信により、ネットワークエレメントがテストパケットを受信した時に応答してきたパス状態の報告を1つ1つ回収することで、データフローが通過する実際のパスを正確に追跡し、ネットワーク管理者が問題があるコンポーネントを更に効率的に探し出すことで故障を排除するのを補佐する。加えて、他のネットワーク管理アプリケーションソフトとの互換性という問題点を考慮し、本発明では判別した情報をパケットのpayloadに記入する手法により、他のネットワーク管理アプリケーションソフトが制限を受けないことを前提にしてテストを行う。これにより他のネットワーク管理アプリケーションソフトと良好に結合し、将来他のネットワーク管理プログラムを開発する時の重要な基礎ツールとなることができる。
【図面の簡単な説明】
【００１９】
【図１】従来型ネットワークの構成図である。
【図２Ａ】従来型ネットワークでのデバッグ方法の表示図である。
【図２Ｂ】従来型ネットワークでのデバッグ方法の表示図である。
【図３】本発明の集中式コントロールプレーンに基づくパス状態の報告演算方法のフローチャートである。
【図４】本発明のテストパケットの伝達フロー表示図である。
【発明を実施するための形態】
【００２０】
本発明の1種の集中式コントロールプレーンに基づくパス状態の報告演算方法は、テストを行いたいデータフロー情報に従いテストパケットを生成してから、始点交換機にテストパケットを送信する。ネットワークで制御を行う各ネットワークエレメントに対し、テストパケットを受信した時に自発的に結果を報告させることで、指定したデータフローがネットワーク内で通過する実際のパスを確認し、ネットワーク環境でのデバッグの判断根拠とする。
【００２１】
本発明のテストフローは、それぞれ生成段階31、テスト段階32及び報告段階33という主に3段階に分かれ、そのフローチャートは図3に示す通りである。
【００２２】
生成段階31では、テストを行いたいデータフローのパケットをシミュレーションしたテストパケットをまず生成し、当該データフローがネットワークで通過することになる実際のパスのテスト用とする。それは、測定が必要なデータフロー情報311を供給する手順と実際のパケットをシミュレーションしてテストパケット312を生成する手順を含む。まず、測定が必要なデータフロー情報を供給311する手順は、例えば送信元MAC、宛先MAC、送信元IP及び宛先IPなど、パケット識別に使える情報など、テストを行いたいデータフロー情報に従い、テストパケットのheaderを生成することで、テストパケットがテストを行いたいデータフローのパケットと同様のルーティングアクションを備える状態を確保する。次に、実際のパケットをシミュレーションしてテストパケット312を生成する手順は、テストパケットのpayloadに専用のキーワードを記入することで、テストパケットと同じheaderを有する他のパケットを識別する。この手法は他のアプリケーションソフトによるパケットheaderの使用と修正を制限せず、それとより良い互換性が保てる。
【００２３】
テストパケットの生成が完了してから、即ちにテスト段階32に入り、テストパケットをネットワーク管理者がテストを行いたいパスが通過する交換機に送信し、パステストを行う。そのうち、交換機は少なくともテストを行いたいパスの始点に位置する交換機とテストを行いたいパスの終点に位置する交換機を含む。その手順は、テストパケットを始点交換機に送信する321手順、交換機が直ちに報告するのを待機後に受信する322手順、終点交換機が報告済323かの判断手順及び時間制限に到達済324かの判断手順を含む。そのうち、テストパケットを始点交換機に送信する321手順は、主に始点交換機に準備段階で生成されたテストパケットを送信するものである。交換機が直ちに報告するのを待機後に受信する322手順は、主に交換機が報告するテストパケットを待機後に受信するものである。終点交換機が報告済323かの判断手順では、主に終点交換機が報告済か否かを判断する。報告済ならば、最終結果の報告331手順に入る。未報告ならば、時間制限に到達済324かの判断手順に入る。時間制限に到達済324かの判断手順では、主にテストの時間制限が到達済か否かを判断する。到達済ならば、最終結果の報告331手順に入る。未到達ならば交換機が直ちに報告するのを待機後に受信する322手順に戻る。
【００２４】
図4が示すテストパケットの伝達フロー表示図により、テスト段階32の実際の作動状況がより良く理解できる。まず、始点交換機46に準備段階で生成したテストパケットを送信する(手順41)。交換機はテストパケットを受信してから、自発的にテストパケットを本発明の演算方法が在する物理サーバに返送してから(手順42)、ルーティング・ルールに従いテストパケットを次の交換機に伝達し(手順43)、これに続くテストを行う。手順41から42までは始点交換機の作動状況をテストし、始点交換機が確実にテストパケットを返送できるか否かを確定するためのものである。これに続くパステストは手順44から手順45までのモードに従い繰り返し行うことで、一段ごとのリンクと交換機の状態をテストする。交換機はテストパケットをサーバに返送することで、状態を報告する(手順44)。続いて、テストパケットをパスにある次の交換機に伝達する(手順45)。
【００２５】
テストを行いたいデータフローの終点交換機がテストパケットを返送すると、又はテストの時間制限に到達すると、直ちに報告段階に入り、それは最終結果の報告331手順を含む。この時、最終結果の報告331手順では、テスト段階時にネットワークエレメント報告の状況に従い集合させたデータフローの実際のパスとパス状態を、ネットワーク管理者に報告する。
【００２６】
本発明はsingle path routing、multipath routing、multicast routingなどの事例を含むがこれらに限定されない、数種類の異なるルーティング事例に適用できる。加えて、本発明の設計では他のネットワーク管理アプリケーションソフトとネットワークエレメントとの互換性を重視しており、他のアプリケーションソフトに影響を及ぼさないことを前提にしてそれと結合し、更に完備されたテストツールを構成すること、又はこれをネットワークの自己最適化に使うことができる。
【００２７】
single pathのデータフローについては、本発明ではそれが通過する実際のパスをテストすることができる。その一方で、multi-pathとmulticastのデータフローなど、通過するパスが1本に留まらないデータフローについては、テストパケットも実際のパケットのように複数個にコピーされるため、本発明は依然として各交換機が返答するパケットに従い、このデータフローが通過する完全なパスとパケットの総量などの情報が分析できる。
【００２８】
本発明ではパケットのpayload内容をテストパケットの判別根拠として使うため、パケットheaderフィールドを使う手法と比べ、他のアプリケーションソフトに影響を及ぼさないことを前提にして、データフローの実際のパスを他のモジュールのテストと最適化の根拠として提供することができる。以下、統合使用の事例をいくつか列挙する。
【００２９】
本発明との結合を通じて、routingアプリケーションソフトはパスを設定してから、データフローの実際のパスと演算論理が一致するか否かを検査し、これをデバッグ根拠とする。Reroutingアプリケーションソフトは本発明のテスト結果に従い、その時点でのパスがスムーズに流れているか否かを知り、パス報告のレイテンシを手に入れる。データフローがその時点でのパスによっては宛先に到達できなくった場合又はレイテンシが長すぎる場合には自動的にパスを交換する。本発明で返答されたデータフローの実際のパスにより、StatisticsとStress Testアプリケーションソフトはデータフローが通過する実際のパスに対し正確に操作を行うことで、ネットワークに及ぼす余分な負担が避けられる。
【００３０】
ネットワーク状態の検知のほかにも、本発明はDHCP Serverなどのサーバの作動状況のテストにも使うことができる。クライアント端末が送り出した実際のパケット内容をテストパケットのheaderとpayload内に個別に記入してから、この実際のパケットをシミュレーションしたテストパケットをクライアント端末に接続する交換機に送信する。こうして、テストパケットが実際のパケットと同じパスを経由してサーバに伝送されてから、サーバの応答パケットを取得して、これをサーバ状態を判断する根拠とすることができる。
【００３１】
本発明の演算方法で中核をなすのは、ネットワークエレメントによるテストパケットを受信した時の報告を一括的に収集し、判別した情報をheaderではなく、payloadに記入することで、他のアプリケーションソフトの作動に影響を与えないようにすることにある。使用するネットワークアーキテクチャが以上の2つの条件を満たすだけで、本発明の演算方法が実装できる。
【００３２】
本発明の演算方法を実装するうちで1つの選択は、SDN(Software-Defined Networking ソフトウェア・デファインド・ネットワーキング)ネットワークアーキテクチャである。私達は本発明の演算方法の実装をSDNのネットワーク管理アプリケーションソフトとし、 SDNネットワークアーキテクチャが持つプログラマブルの特性を利用してSDN交換機の転送アクションを定義することができる。こうして、あらゆるSDN交換機がテストパケットを受信した時に、元のルーティング・ルールに従い転送するほかにも、パス状態の情報を本発明のアプリケーションソフトに報告できるようになる。こうして集中制御の設計を実現するのである。
【００３３】
本発明の1種の集中式コントロールプレーンに基づくパス状態の報告演算方法は従来型従来技術と互いに比較すると、更に下記の長所を備えるのが分かる。
【００３４】
本発明の1種の集中式コントロールプレーンに基づくパス状態の報告演算方法により、データフローが通過する実際のパス状態が追跡できる。
【００３５】
1. pingに比べて、本発明ではより多くのネットワーク情報をネットワーク管理者に報告することができる。
【００３６】
2. tracerouteに比べて、本発明では比較的少ない通信量で、制御するネットワークにある指定されたデータフローが通過する実際のパスを探し出し、検知動作がネットワークに及ぼす負担が減らせる。
【００３７】
3. SDN tracerouteに比べて、本発明がパケットのpayload内容をテストパケットの判別根拠として使い、他のアプリケーションソフトによるパケットheaderの使用と修正を制限しないため、他のネットワーク管理アプリケーションソフトとの高い互換性を前提にして、正確なテスト結果が得られる。
【００３８】
4. 本発明は他のネットワーク管理アプリケーションソフトとネットワークエレメントとの互換性を重視し、他のアプリケーションソフトに影響を及ぼさないことを前提にしてそれと結合し、更に完備されたテストツールを構成すること、又はこれをネットワークの自己最適化に使うことができる。
【００３９】
5. 本発明は集中式のコントロールプレーンによるパス状態の報告演算メカニズムを導入しており、データフローが通過する実際のパスを追跡し、ネットワーク管理者とネットワーク管理アプリケーションソフトに更に効率的に障害を分析・排除する能力を提供することができ、大幅にCAPEX及びOPEXが減らせる。
【００４０】
上述の詳細な説明では、本発明の実行可能な実施例について具体的な説明を行った。ただし当該実施例は本発明の特許請求の範囲を限定するためのものではない。本発明の技能と趣旨を逸脱しない同等の効果を有する実施又は変更は全て、本件特許の特許請求の範囲に含まれる。
【００４１】
上記の内容を総括すると、本件特許は技術構想面で確かに革新的であるのみならず、一般的な従来型の方法では及ばない上述の複数項の効果を備え、すでに新規性と進歩性という発明特許の法律要件に十分に合致していることにより、法に基づき出願を行う。貴局には本発明特許出願案件への査定を行うことで、これを発明奨励への機会にしていただければ光栄である。
【符号の説明】
【００４２】
11    コントロールプレーン
12    データプレーン
13    ネットワーク管理者
21    ログ
22    reply
31    生成段階
32    テスト段階
33    報告段階
311   測定が必要なデータフロー情報を供給
312   実際のパケットをシミュレーションしたテストパケットを生成
321   テストパケットを始点交換機に送信
322   交換機が直ちに報告するのを待機後に受信
323   終点交換機が報告済
324   時間制限に到達済
331   最終結果を報告
41    始点交換機にテストパケットを送信
42    始点交換機がテストパケットを物理サーバに返送
43    ルーティング・ルールに従いテストパケットを次の交換機に伝達
44    交換機がテストパケットをサーバに返送することで状態を報告
45    テストパケットをパスにある次の交換機に伝達
46    始点交換機
【図１】
0006591950.tif 000002
【図２Ａ】
0006591950.tif 000003
【図２Ｂ】
0006591950.tif 000004
【図３】
0006591950.tif 000005
【図４】
0006591950.tif 000006