(57)【要約】【課題】仮想マシンからのブロードキャストを抑制する。【解決手段】物理マシン上で動作する仮想マシンが処理を要求するホストのアドレスを保持するアクセス先記憶手段と、前記仮想マシンから送信されるブロードキャストフレームを受信するフレーム受信手段と、前記ブロードキャストフレームの宛先アドレスを前記アクセス先記憶手段に保持される前記アドレスで書き換えるフレーム書換手段と、前記宛先アドレスを書き換えた前記ブロードキャストフレームを送信するフレーム送信手段とを有する。【選択図】図４
2008028914.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のアクセス先を検出して前記アクセス先の宛先情報を取得する端末装置と、
前記端末装置が取得した前記宛先情報を保持し、且つ、前記端末装置からフレームを受信した時、前記宛先情報に基づいて前記フレームの宛先を前記アクセス先とした少なくとも一つのユニキャスト用フレームを作成する監視装置と
を具備する
通信負荷低減装置。
【請求項２】
請求項１に記載の通信負荷低減装置において、
前記監視装置は、前記端末装置にアクセス先登録要求を行い、且つ、前記端末装置から通知された前記宛先情報を取得し、
前記端末装置は、前記監視装置からアクセス先登録要求を受信したことをマークし、且つ、前記アクセス先から応答を受信した時にアクセス先登録要求がマークされている場合、前記監視装置に前記宛先情報を通知する
通信負荷低減装置。
【請求項３】
請求項１又は２に記載の通信負荷低減装置において、
前記監視装置は、
前記宛先情報としてサーバのアドレス情報を格納するアクセス先記憶部と、
前記端末装置から前記フレームを受信し、前記フレームが所定のメッセージであるか確認するフレーム受信部と、
前記フレームが所定のメッセージである場合、前記アクセス先記憶部に格納されている前記アドレス情報に基づき前記フレームの宛先アドレスを書き換えるフレーム書換部と、
前記宛先アドレスに対して前記フレームを送信するフレーム送信部と
を具備する
通信負荷低減装置。
【請求項４】
請求項３に記載の通信負荷低減装置において、
前記フレーム書換部は、前記アドレス情報を複数保有しているか確認し、前記アドレス情報の数に応じてバッファサイズを決定し、前記少なくとも一つのユニキャスト用フレームのバッファのアロケートを行い、前記フレームと前記アドレス情報に基づいて、前記アドレス情報毎に対応する各サーバを宛先として、アロケートしたバッファに前記少なくとも一つのユニキャスト用フレームを作成し、
前記フレーム送信部は、前記少なくとも一つのユニキャスト用フレームを送信する
通信負荷低減装置。
【請求項５】
請求項３又は４に記載の通信負荷低減装置において、
前記フレーム書換部は、前記アドレス情報を登録した時刻から所定時刻が経過した場合、前記フレームの宛先アドレスを書き換えることなく、アクセス先登録要求を行う
通信負荷低減装置。
【請求項６】
請求項３乃至５のいずれか一項に記載の通信負荷低減装置において、
前記フレーム書換部は、前記フレームがＡＲＰである場合、問い合わせようとするＩＰアドレスのＭＡＣアドレスを保有しているか確認し、前記ＭＡＣアドレスを保有している場合、前記ＭＡＣアドレスで前記フレームの宛先アドレスを書き換える
通信負荷低減装置。
【請求項７】
請求項３乃至６のいずれか一項に記載の通信負荷低減装置において、
前記フレーム書換部は、前記フレームが所定のフレームである場合、ｉに１を設定し、ポインターテーブルのサービスｉのテーブルポインターがＮＵＬＬかどうかを検査し、ＮＵＬＬでない場合、サービスｉのアクセス処理を行い、ｉに１を加算し、再度サービスｉのテーブルポインターがＮＵＬＬかどうかの検査を行う
通信負荷低減装置。
【請求項８】
請求項１乃至７のいずれか一項に記載の通信負荷低減装置において、
前記端末装置は、物理マシン上で動作する仮想マシンであり、
前記監視装置は、前記仮想マシンを監視する仮想マシンモニタである
通信負荷低減装置。
【請求項９】
（ａ１）フレームを取得し、前記フレームが所定のメッセージかを確認するステップと、
（ａ２）前記フレームが所定のメッセージである場合、アクセス先アドレスとしてサーバのアドレス情報が格納されているかを確認するステップと、
（ａ３）サーバのアドレス情報が格納されている場合、格納されているサーバのアドレス情報で前記フレームの宛先アドレスを書き換えるステップと、
（ａ４）アクセス先アドレスとしてサーバのアドレス情報が格納されていない場合、アクセス先登録要求処理を起動するステップと
を具備する
通信負荷低減方法。
【請求項１０】
請求項９に記載の通信負荷低減方法において、
（ｂ１）前記アクセス先登録要求処理を起動すると、アクセス先登録要求を行うステップと、
（ｂ２）アクセス先登録要求があったことをマークするステップと、
（ｂ３）サーバから応答を受信することでサーバを確定し、アクセス先登録要求がマークされているか否かを確認するステップと、
（ｂ４）アクセス先登録要求がマークされていると、確定したサーバのアドレス情報を取得するステップと、
（ｂ５）確定したサーバのアドレス情報を格納するステップと
を更に具備する
通信負荷低減方法。
【請求項１１】
請求項９又は１０に記載の通信負荷低減方法において、
前記（ａ３）ステップは、
（ａ３１）アクセス先アドレスとしてサーバのアドレス情報が格納されている場合、サーバのアドレス情報が複数格納されているかを確認するステップと、
（ａ３２）サーバのアドレス情報が１つ格納されている場合、格納されているサーバのアドレス情報で前記フレームの宛先アドレスを書き換えるステップと、
（ａ３３）サーバのアドレス情報が複数格納されている場合、格納されているサーバ数に応じてバッファサイズを決定し、少なくとも一つのユニキャスト用フレームバッファのアロケートを行うステップと、
（ａ３４）前記フレームとサーバのアドレス情報に基づいて、該当するサーバを宛先とするように、アロケートしたバッファに少なくとも一つのユニキャスト用フレームを作成するステップと、
（ａ３５）前記少なくとも一つのユニキャスト用フレームをフレーム送信部で送信するステップと
を具備する
通信負荷低減方法。
【請求項１２】
請求項９乃至１１のいずれか一項に記載の通信負荷低減方法において、
前記（ａ２）ステップは、
（ａ２１）前記フレームが所定のメッセージであると判断した場合でも、サーバのアドレス情報を格納した時刻から所定時刻が経過した場合は、前記フレームの宛先アドレスを書き換えることなく、アクセス先登録要求処理を起動するステップと
を具備する
通信負荷低減方法。
【請求項１３】
請求項９乃至１２のいずれか一項に記載の通信負荷低減方法において、
（ｃ１）前記フレームがＡＲＰかどうかを検査するステップと、
（ｃ２）前記フレームがＡＲＰであった場合、問い合わせようとするＩＰアドレスのＭＡＣアドレスが既に記憶されているか検査するステップと、
（ｃ３）前記ＭＡＣアドレスが既に記憶されていれば、前記ＭＡＣアドレスで前記所定のフレームの宛先アドレスを書き換えるステップと、
（ｃ４）前記ＭＡＣアドレスが記憶されていない場合、ＡＲＰである前記フレームを送信した端末装置に対するアクセス先登録要求処理を起動するステップと
を更に具備する
通信負荷低減方法。
【請求項１４】
請求項９乃至１３のいずれか一項に記載の通信負荷低減方法において、
（ｄ１）ｉに１を設定するステップと、
（ｄ２）ポインターテーブルのサービスｉのテーブルポインターがＮＵＬＬかどうかを検査するステップと、
（ｄ３）サービスｉのテーブルポインターＮＵＬＬであれば、処理を終了するステップと、
（ｄ４）サービスｉのテーブルポインターＮＵＬＬでなければ、サービスｉのアクセス処理を行った後、ｉに１を加算し、サービスｉのテーブルポインターがＮＵＬＬかどうかの検査を行うステップと
を更に具備する
通信負荷低減方法。
【請求項１５】
請求項９乃至１４のいずれか一項に記載の通信負荷低減方法を、コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信負荷低減装置に関し、特に端末からのフレームの送出を抑制する通信負荷低減装置に関する。
【背景技術】
【０００２】
ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ：仮想マシン）を利用して複数台のクライアントを統合した環境において、ＩＰアドレスの設定は、クライアント・サーバ方式の一つであるＤＨＣＰ（Ｄｙｎａｍｉｃ  Ｈｏｓｔ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）サービスを利用する場合が多いと考えられる。各クライアントには仮想ＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）が割り当てられ、物理ＮＩＣを通してＬＡＮとつながっている。
【０００３】
ＤＨＣＰサーバを、統合したクライアントと同じマシン（ハイパーバイザ）上に１つのＶＭを利用して置いた場合、同じハイパーバイザ上のＶＭのクライアントからのＤＨＣＰ要求をブロードキャストすることはネットワーク帯域の無駄である。また、この場合のＤＨＣＰサーバが、ハイパーバイザ環境以外から利用されたり、逆にハイパーバイザ上のＶＭのクライアントが他のＤＨＣＰサーバからＩＰアドレスを取得してしまう可能性がある。
【０００４】
ネットワークへの問合せに際し、相手先が事前にわからない場合、ブロードキャストを用いて一斉に問い合わせる。ＤＨＣＰを例にとり、更に説明する。ノードのＩＰアドレスは、ネットワーク管理者によってノード個別に手動で設定する場合と、自動的に設定する場合とがあるが、後者の仕組みとして考えられたのが、ＤＨＣＰと呼ばれるプロトコルである。以下、ＲＦＣ２１３１での規定に基づいて、ＤＨＣＰでのブロードキャストの使い方を説明する。なお、ＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ）とは、インターネットに関する技術の標準を定める団体が正式に発行する文書である。ＩＰ（ＲＦＣ７９１）、ＴＣＰ（ＲＦＣ７９３）、ＨＴＴＰ（ＲＦＣ２６１６）、ＦＴＰ（ＲＦＣ９５９）のようにインターネットで利用されるプロトコルや、その他インターネットに関わるさまざまな技術の仕様・要件を、通し番号をつけて公開している
【０００５】
ＤＨＣＰは、指定されたＤＨＣＰサーバがネットワークアドレスを動的に割り当て、コンフィグレーションパラメータとともにホストに送信する。
【０００６】
ＤＨＣＰはＲＦＣ９５１に定められている、ＢＯＯＴＰと同じメッセージを使用している。ＤＨＣＰサーバからコンフィグレーションデータを受け取るＤＨＣＰクライアントからＤＨＣＰサーバに送られるメッセージでは、「オペレーションコード」はＢＯＯＴＲＥＱＵＥＳＴになっており、ＤＨＣＰサーバからＤＨＣＰクライアントに送られるメッセージではＢＯＯＴＲＥＰＬＹとなっている。
【０００７】
ＤＨＣＰメッセージのいくつかを図１に例示する。ＤＨＣＰでは、ＤＨＣＰクライアントは、ＤＨＣＰサーバのアドレスを知らない場合に、ＤＨＣＰＤＩＳＣＯＶＥＲ、ＤＨＣＰＲＥＱＵＥＳＴ、ＤＨＣＰＩＮＦＯＲＭをブロードキャストする。
【０００８】
図２を参照し、例として、ＤＨＣＰＤＩＳＣＯＶＥＲ、ＤＨＣＰＲＥＱＵＥＳＴのフローについて説明する。
（１）ステップＳ１
まず、ＤＨＣＰクライアントが、ＤＨＣＰＤＩＳＣＯＶＥＲをローカルサブネットにブロードキャストする。
（２）ステップＳ２、ステップＳ２´
ＤＨＣＰＤＩＳＣＯＶＥＲを受け取ったＤＨＣＰサーバは、「割り当てＩＰアドレス」や他のオプションを含むＤＨＣＰＯＦＦＥＲを応答する。
（３）ステップＳ３
ＤＨＣＰクライアントは、複数のＤＨＣＰサーバから一つ以上のＤＨＣＰＯＦＦＥＲを受信するまで待機する。
（４）ステップＳ４
ＤＨＣＰクライアントは、複数のＤＨＣＰサーバから一つ以上のＤＨＣＰＯＦＦＥＲを受信した際、そのＤＨＣＰＯＦＦＥＲにあるコンフィグレーション情報をチェックして、それをもとにどれか一つのＤＨＣＰサーバを選択する。
（５）ステップＳ５
ＤＨＣＰクライアントは、そのＤＨＣＰサーバが選択されたことを示すための「サーバＩＤ」を含めたＤＨＣＰＲＥＱＵＥＳＴをブロードキャストする。ＤＨＣＰサーバはＤＨＣＰクライアントがブロードキャストしたＤＨＣＰＲＥＱＵＥＳＴを受信するが、「サーバＩＤ」により指定されていないＤＨＣＰサーバはそのＤＨＣＰＲＥＱＵＥＳＴにより、ＤＨＣＰクライアントが別のＤＨＣＰサーバを選択したことを認識する。
（６）ステップＳ６
指定されたＤＨＣＰサーバは、リソースをとり置くとともにＤＨＣＰＡＣＫに要求のあったコンフィグレーション情報を含めて応答する。ＤＨＣＰクライアントは要求したコンフィグレーション情報の入ったＤＨＣＰＡＣＫを受信すると、パラメータのチェック（ＡＲＰで割り当てられたネットワークアドレスのチェックをするなど）を行い、リース期間などを記録しておく。これで、ＤＨＣＰクライアントのコンフィグレーションが終了したことになる。
【０００９】
ＤＨＣＰＩＮＦＯＲＭのやり取りについて説明する。ＤＨＣＰクライアントがＤＨＣＰ以外の方法でネットワークアドレスを取得した場合に、他のローカルパラメータを取得するためには、ＤＨＣＰＩＮＦＯＲＭをブロードキャストする。ＤＨＣＰＩＮＦＯＲＭメッセージを受信したＤＨＣＰサーバは、アドレスの割り当てや既存のリースのチェックや「割り当てＩＰアドレス」や「リース期間」の設定をすることなく、ＤＨＣＰクライアントに適したローカルパラメータをＤＨＣＰＡＣＫに含めて応答する。ＤＨＣＰサーバはＤＨＣＰＩＮＦＯＲＭの「クライアントＩＰアドレス」にダイレクトにＤＨＣＰＡＣＫメッセージを送付する。
【００１０】
次に、図３を参照して、ＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）におけるブロードキャスト処理を説明する。ＡＲＰは、ＴＣＰ／ＩＰネットワークにおいて、ＩＰアドレスからイーサネット（登録商標）の物理アドレス（ＭＡＣアドレス）を求めるのに使われるプロトコルである。ＡＲＰはＲＦＣ８２６で規定されている。なお、ＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスは、通信用インタフェース（ＮＩＣ）に固有のＩＤ番号である。
（１）ステップＳ１１
ネットワーク上のホスト１が、「ＩＰアドレス１」というＩＰアドレスを持つホストのＭＡＣアドレスを知りたい場合、ＡＲＰを使い、ブロードキャストパケットを送信する。
（２）ステップＳ１２
ホスト１は、ＡＲＰに対する応答を受け取るまで待機する。
（３）ステップＳ１３
このブロードキャストを受信したそれぞれのホストは、自分のＩＰアドレスが送信された「ＩＰアドレス１」と一致するか検査を行う。
（４）ステップＳ１４
「ＩＰアドレス１」と一致するホストは、自分のＭＡＣアドレスをホスト１に返信する。ここでは、ホスト２が「ＩＰアドレス１」と一致するため、ホスト２が自分のＭＡＣアドレスをホスト１に返信する。
【００１１】
上記のようなブロードキャストは、ローカルエリアネットワークに大きな負担を与える。パケット自体は、ユニキャストでもブロードキャストでも、イーサネットを共有しているコンピュータすべてに配送される。但し、ネットワークスイッチを使用している場合には、ユニキャストは、ネットワークスイッチによってフィルターが可能である。ユニキャストは指定されているあて先ＭＡＣアドレスを持つコンピュータ以外は、ＮＩＣで処理され、それ以上の階層に行かない。しかし、ブロードキャストの場合は、ＮＩＣでは処理できず、それより上の階層にまで送られ、そのコンピュータのＯＳやアプリケーションで処理されることになる。このため、コンピュータ資源が無駄に消費されてしまう。
【００１２】
このような問題は、生成・消滅がより頻繁に行われる仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ環境）で顕著になる。仮想マシンが生成され、上述したＤＨＣＰ方式で新たにＩＰアドレスの割当を求める場合、その仮想マシンはＤＨＣＰサーバの所在がわからないため、ブロードキャストを行う。このため、ネットワークにつながれている他のコンピュータもネットワーク層レベルまでパケットが送られ、ＣＰＵ資源を消費してようやく自分宛ではないと判断することになる。この処理の間は、当該コンピュータ上の他の処理に影響を与えることとなる。しかし、その仮想マシンが生成された物理マシン上では、既に他の仮想マシンが生成・起動され、当該他の仮想マシンによるブロードキャストによって、既にＤＨＣＰサーバの所在が把握できている場合がある。このように、ネットワーク上のあるホスト（物理マシン）上で複数の仮想マシンが生成され得るような場合には、先に生成・起動された仮想マシンによって、ＤＨＣＰサーバのアドレスを知ることができるため、そのホスト上で後に生成・起動された仮想マシンによるブロードキャストは、冗長なものである。
【００１３】
同様に、ＡＲＰでＭＡＣアドレスを問い合わせる場合も同様である。物理マシン上の仮想マシンで既にあるＩＰアドレスに対応するホストのＭＡＣアドレスを入手している場合、同じ物理マシン上の他の仮想マシンからの同じＩＰアドレスの問合せのためのブロードキャストは、冗長である。
【００１４】
関連する技術として、特開２０００−５９３８７号公報（特許文献１）では、ＤＨＣＰクライアントからのＤＨＣＰＤＩＳＣＯＶＥＲメッセージに対し、特定のＤＨＣＰサーバのみがＤＨＣＰＯＦＦＥＲメッセージを送信する技術について記載している。ＤＨＣＰクライアントはＤＨＣＰＤＩＳＣＯＶＥＲメッセージをブロードキャストするが、これを受けた各ＤＨＣＰサーバはクＤＨＣＰライアントが自己の管理対象ホストであるか否かを判断する。管理対象ホストでなければＤＨＣＰＤＩＳＣＯＶＥＲメッセージを廃棄し、管理対象ホストであればＤＨＣＰＯＦＦＥＲをブロードキャストする。ＤＨＣＰクライアントは、応答を返したＤＨＣＰサーバに対してＤＨＣＰＲＥＱＵＥＳＴメッセージをユニキャストで送信する。
【００１５】
特開２００４−１０４１９９号公報（特許文献２）では、ＤＨＣＰサーバの負荷分散について記載している。同一のローカルエリアネットワークに複数のＤＨＣＰサーバが設けられている場合、最先に情報を応答したＤＨＣＰサーバが選択されることが多いため、特定のＤＨＣＰサーバに負荷が大きくなることがある。これを解決するために、ＤＨＣＰクライアントは、予め登録されているＤＨＣＰサーバのＩＰアドレスを保存し、その保存したＩＰアドレスと一致するＩＰアドレスを有するＤＨＣＰサーバに対してネットワークパラメータの取得を要求するようにしている。
【００１６】
特開２００１−２３０７８８号公報（特許文献３）では、ＤＨＣＰサーバの故障に備えるため、ローカルエリアネットワーク内で複数のＤＨＣＰサーバが存在し、それらが同一のＩＰアドレスプールを保持することを記載している。
【００１７】
しかし、上記いずれの先行技術文献においても、ブロードキャストを抑制する手段が開示されていない。
【００１８】
特開２０００−５９３８７号公報（特許文献１）では、ＤＨＣＰＤＩＳＣＯＶＥＲメッセージや、ＤＨＣＰＯＦＦＥＲメッセージがブロードキャストされる。特開２００４−１０４１９９号公報（特許文献２）では、立ち上げ直後のまだＤＨＣＰクライアントのＩＰアドレスが定まっていない場合には、通常の手順に従い、ブロードキャストが用いられる。特開２００１−２３０７８８号公報（特許文献３）でも、ブロードキャストの抑制については何ら記載がない。
【００１９】
【特許文献１】特開２０００−５９３８７号公報
【特許文献２】特開２００４−１０４１９９号公報
【特許文献３】特開２００１−２３０７８８号公報
【発明の開示】
【発明が解決しようとする課題】
【００２０】
本願発明の目的は、ＶＭ環境における処理要求に際してのフレームの発生を抑制する通信負荷低減装置を提供することである。
本願発明の他の目的は、ネットワークの負荷の増大を抑える通信負荷低減装置を提供することである。
本発明の更に他の目的は、ローカルブロードキャストであるＤＨＣＰアドレス取得要求を、ハイパーバイザ上ではブロードキャストせずに、ＤＨＣＰサーバへのユニキャストとする通信負荷低減装置を提供することである。
本発明の更に他の目的は、ＩＰアドレス等の設定が完了してから、そのクライアントをＬＡＮに接続する通信負荷低減装置を提供することである。
【課題を解決するための手段】
【００２１】
以下に、［発明を実施するための最良の形態］で使用される番号を括弧付きで用いて、課題を解決するための手段を説明する。これらの番号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために付加されたものである。但し、それらの番号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。
【００２２】
本発明の通信負荷低減装置（１００，５００）は、ネットワーク上のアクセス先を検出してアクセス先の宛先情報を取得する端末装置（１２０−１，５２０−１）と、端末装置（１２０−１，５２０−１）が取得した宛先情報を保持し、且つ、端末装置（１２０−１，５２０−１）からフレームを受信した時、宛先情報に基づいてフレームの宛先をアクセス先とした少なくとも一つのユニキャスト用フレームを作成する監視装置（１１０，５１０）とを具備する。
【００２３】
監視装置（１１０，５１０）は、端末装置（１２０−１，５２０−１）にアクセス先登録要求を行い、且つ、端末装置（１２０−１，５２０−１）から通知された宛先情報を取得する。端末装置（１２０−１，５２０−１）は、監視装置（１１０，５１０）からアクセス先登録要求を受信したことをマークし、且つ、アクセス先から応答を受信した時にアクセス先登録要求がマークされている場合、監視装置（１１０，５１０）に宛先情報を通知する。
【００２４】
監視装置（１１０，５１０）は、宛先情報としてサーバ（１２０−２，３００）のアドレス情報を格納するアクセス先記憶部（１１１，５１１）と、端末装置（１２０−１，５２０−１）からフレームを受信し、フレームが所定のメッセージであるか確認するフレーム受信部（１１２，５１２）と、フレームが所定のメッセージである場合、アクセス先記憶部（１１１，５１１）に格納されているアドレス情報に基づきフレームの宛先アドレスを書き換えるフレーム書換部（１１３，５１３）と、宛先アドレスに対してフレームを送信するフレーム送信部（１１４，５１４）とを具備する。
【００２５】
フレーム書換部（１１３，５１３）は、アドレス情報を複数保有しているか確認し、アドレス情報の数に応じてバッファサイズを決定し、少なくとも一つのユニキャスト用フレームのバッファのアロケートを行い、フレームとアドレス情報に基づいて、アドレス情報毎に対応する各サーバ（１２０−２，３００）を宛先として、アロケートしたバッファに少なくとも一つのユニキャスト用フレームを作成する。フレーム送信部（１１４，５１４）は、少なくとも一つのユニキャスト用フレームを送信する。
【００２６】
フレーム書換部（１１３，５１３）は、アドレス情報を登録した時刻から所定時刻が経過した場合、フレームの宛先アドレスを書き換えることなく、アクセス先登録要求を行う。
【００２７】
フレーム書換部（１１３，５１３）は、フレームがＡＲＰである場合、問い合わせようとするＩＰアドレスのＭＡＣアドレスを保有しているか確認し、ＭＡＣアドレスを保有している場合、ＭＡＣアドレスでフレームの宛先アドレスを書き換える。
【００２８】
フレーム書換部（１１３，５１３）は、フレームが所定のフレームである場合、ｉに１を設定し、ポインターテーブルのサービスｉのテーブルポインターがＮＵＬＬかどうかを検査し、ＮＵＬＬでない場合、サービスｉのアクセス処理を行い、ｉに１を加算し、再度サービスｉのテーブルポインターがＮＵＬＬかどうかの検査を行う。
【００２９】
端末装置（１２０−１，５２０−１）は、物理マシン上で動作する仮想マシンでも良い。
監視装置（１１０，５１０）は、仮想マシンを監視する仮想マシンモニタでも良い。
【００３０】
本発明の通信負荷低減方法及びプログラムは、（ａ１）フレームを取得し、フレームが所定のメッセージかを確認するステップと、（ａ２）フレームが所定のメッセージである場合、アクセス先アドレスとしてサーバ（１２０−２，３００）のアドレス情報が格納されているかを確認するステップと、（ａ３）サーバ（１２０−２，３００）のアドレス情報が格納されている場合、格納されているサーバ（１２０−２，３００）のアドレス情報でフレームの宛先アドレスを書き換えるステップと、（ａ４）アクセス先アドレスとしてサーバ（１２０−２，３００）のアドレス情報が格納されていない場合、アクセス先登録要求処理を起動するステップとを具備する。
【００３１】
本発明の通信負荷低減方法及びプログラムは、（ｂ１）アクセス先登録要求処理を起動すると、アクセス先登録要求を行うステップと、（ｂ２）アクセス先登録要求があったことをマークするステップと、（ｂ３）サーバ（１２０−２，３００）から応答を受信することでサーバ（１２０−２，３００）を確定し、アクセス先登録要求がマークされているか否かを確認するステップと、（ｂ４）アクセス先登録要求がマークされていると、確定したサーバ（１２０−２，３００）のアドレス情報を取得するステップと、（ｂ５）確定したサーバ（１２０−２，３００）のアドレス情報を格納するステップとを更に具備する。
【００３２】
（ａ３）ステップは、（ａ３１）アクセス先アドレスとしてサーバ（１２０−２，３００）のアドレス情報が格納されている場合、サーバ（１２０−２，３００）のアドレス情報が複数格納されているかを確認するステップと、（ａ３２）サーバ（１２０−２，３００）のアドレス情報が１つ格納されている場合、格納されているサーバ（１２０−２，３００）のアドレス情報でフレームの宛先アドレスを書き換えるステップと、（ａ３３）サーバ（１２０−２，３００）のアドレス情報が複数格納されている場合、格納されているサーバ（１２０−２，３００）数に応じてバッファサイズを決定し、少なくとも一つのユニキャスト用フレームバッファのアロケートを行うステップと、（ａ３４）フレームとサーバ（１２０−２，３００）のアドレス情報に基づいて、該当するサーバ（１２０−２，３００）を宛先とするように、アロケートしたバッファに少なくとも一つのユニキャスト用フレームを作成するステップと、（ａ３５）少なくとも一つのユニキャスト用フレームをフレーム送信部（１１４，５１４）で送信するステップとを具備する。
【００３３】
（ａ２）ステップは、（ａ２１）フレームが所定のメッセージであると判断した場合でも、サーバ（１２０−２，３００）のアドレス情報を格納した時刻から所定時刻が経過した場合は、フレームの宛先アドレスを書き換えることなく、アクセス先登録要求処理を起動するステップとを具備する。
【００３４】
本発明の通信負荷低減方法及びプログラムは、（ｃ１）フレームがＡＲＰかどうかを検査するステップと、（ｃ２）フレームがＡＲＰであった場合、問い合わせようとするＩＰアドレスのＭＡＣアドレスが既に記憶されているか検査するステップと、（ｃ３）ＭＡＣアドレスが既に記憶されていれば、ＭＡＣアドレスで所定のフレームの宛先アドレスを書き換えるステップと、（ｃ４）ＭＡＣアドレスが記憶されていない場合、ＡＲＰであるフレームを送信した端末装置（１２０−１，５２０−１）に対するアクセス先登録要求処理を起動するステップとを更に具備する。
【００３５】
本発明の通信負荷低減方法及びプログラムは、（ｄ１）ｉに１を設定するステップと、（ｄ２）ポインターテーブルのサービスｉのテーブルポインターがＮＵＬＬかどうかを検査するステップと、（ｄ３）サービスｉのテーブルポインターＮＵＬＬであれば、処理を終了するステップと、（ｄ４）サービスｉのテーブルポインターＮＵＬＬでなければ、サービスｉのアクセス処理を行った後、ｉに１を加算し、サービスｉのテーブルポインターがＮＵＬＬかどうかの検査を行うステップとを更に具備する。
【発明の効果】
【００３６】
無駄なブロードキャストを排除することができる。従って、ネットワーク上の負荷を削減できる。また、ＶＭのクライアント群のために用意したＩＰアドレス群を、正しく配付することが可能となる。
【発明を実施するための最良の形態】
【００３７】
以下に本発明の第１実施形態について添付図面を参照して説明する。
図４を参照すると、本発明の通信負荷低減装置は、物理マシン１００と、通信路２００と、ホスト３００とを備えている。物理マシン１００は、仮想マシンモニタ１１０と、仮想マシン１２０とを備えている。仮想マシンモニタ１１０及び仮想マシン１２０（１２０−ｋ、ｋ＝１〜ｎ：ｎは仮想マシン数）は、物理マシン１００上で動作する。
【００３８】
仮想マシンモニタ１１０は、ＶＭＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｍｏｎｉｔｏｒ）や、ハイパーバイザと呼ばれるものであっても良い。仮想マシン１２０は、物理マシン１００により生成・起動されるＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）である。通信路２００は、例えばイーサネット（登録商標）など、ブロードキャスト通信をサポートするネットワークである。
【００３９】
なお、仮想マシンモニタ１１０と仮想マシン１２０は、それぞれ個別の処理装置（ＣＰＵ）により実行されるプログラムでも良い。この時、仮想マシンモニタ１１０として動作する処理装置と仮想マシン１２０として動作する処理装置との間でデータ通信を行う。
【００４０】
仮想マシンモニタ１１０は、アクセス先記憶部１１１と、フレーム受信部１１２と、フレーム書換部１１３と、フレーム送信部１１４とを含む。アクセス先記憶部１１１は、所定の処理を行うホストのアドレスを格納する。フレーム受信部１１２は、仮想マシン１２０から送信されるフレーム（Ｆｒａｍｅ）を受信する。なお、フレームとは、特定のプロトコルで用いられるデータフォーマットのデータである。通常は、データリンク層のパケットであり、送信元アドレス及び宛先アドレスが含まれる。フレーム書換部１１３は、そのフレームの宛先アドレスをアクセス先記憶部１１１に格納されている情報に基づいて書き換える。フレーム送信部１１４は、前記フレームを送信する。
【００４１】
ここで、所定の処理としては、ＤＨＣＰを始め、ブロードキャストでネットワークに対して問合せを行う処理がある。以下ではＤＨＣＰを例にとって説明を行う。また、通信路２００については、イーサネットを例にとった説明とする。
【００４２】
アクセス先記憶部１１１は、メモリで構成する。また、ディスクで構成することもできる。ＤＨＣＰサーバのアドレスを格納する。ＤＨＣＰサーバのアドレスとして、ＩＰアドレスと、ＭＡＣアドレスの双方を格納するものとする。これらの情報は、物理マシン１００上でＤＨＣＰクライアントとして動作し、ＤＨＣＰサーバのアドレスを取得した仮想マシンから入手する。なお、アクセス先記憶部１１１には、ＤＨＣＰサーバのアドレス情報として、ＩＰアドレスのみを記憶し、これに対応するＭＡＣアドレスはＡＲＰテーブルから取得するという構成にしても良い。
【００４３】
フレーム受信部１１２は、ＤＨＣＰクライアントとして動作する仮想マシン１２０−１からのブロードキャストフレームが通信路２００上に出る前に受信する。この時、受信したフレームが所定の条件を満たしているかどうか判定する。フレームのフォーマットは、イーサネットのＣＤＭＡ／ＣＤアクセス制御方式では、図５のようになっている。なお、宛先アドレス及び送信元アドレスには、それぞれＩＰアドレスとＭＡＣアドレスとが含まれる。
【００４４】
フレーム書換部１１３は、フレーム受信部１１２で受信したフレームが所定の条件を満たしている場合に、このフレームの宛先アドレスを書き換える。なお、フレーム書換部１１３において、フレームが所定の条件を満たしているかどうか判定するようにすることも可能である。
【００４５】
フレーム送信部１１４は、上記フレームをフレームの宛先アドレスに送信する。フレーム送信部１１４は、宛先アドレスがネットワーク上にある他のホストのものである場合には、図６のように通信路２００にフレームを送出する。一方、宛先アドレスが自己が属する物理マシン１００上のものである場合、図７に示すように、その宛先アドレスを有する仮想マシン１２０−２に直接送信する。宛先アドレスが自物理マシン１００上のものか否かの判断は、例えば宛先アドレスのＭＡＣアドレスと、自物理マシン１００上の仮想マシン１２０のＭＡＣアドレスを比較することで行うことができる。
【００４６】
なお、物理マシン１００が一般的なコンピュータである場合、通信用インタフェース（ＮＩＣ）がフレームの送受信を行い、処理装置（ＣＰＵ）が判定その他の処理を行い、記憶装置（メモリ、ハードディスク）がフレームや他の情報を格納する。すなわち、フレーム受信部１１２及びフレーム送信部１１４は通信用インタフェースと処理装置の組み合わせ、フレーム書換部１１３は処理装置、アクセス先記憶部１１１は記憶装置により構成することが可能である。なお、仮想マシンモニタ１１０と仮想マシン１２０との間の通信は物理マシン１００上での動作であるため、実際には、通信用インタフェース（ＮＩＣ）を使用せず、それぞれのプログラム間でのフレームフォーマットのデータのやり取りで済ませる場合もある。
【００４７】
次に、図８のフローチャートを参照して本発明の第１実施形態の動作について詳細に説明する。
（１）ステップＳ１０１
仮想マシンモニタ１１０は、仮想マシン１２０−１から送信されたフレームをフレーム受信部１１２で受信すると、そのフレームが、ブロードキャストフレームかを確認する。この確認には、図９に示すようなＤＨＣＰメッセージフォーマットにおいて、宛先アドレスがブロードキャストアドレスかどうかで判断する。
（２）ステップＳ１０２
このフレームがブロードキャストフレームの場合、フレーム書換部１１３は、このフレームがＤＨＣＰメッセージかを確認する。
（３）ステップＳ１０３
このフレームがＤＨＣＰメッセージである場合、フレーム書換部１１３は、アクセス先記憶部１１１を参照し、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されているかを確認する。
（４）ステップＳ１０４
ＤＨＣＰサーバのアドレス情報が格納されている場合、フレーム書換部１１３は、格納されているＤＨＣＰサーバのアドレス情報でＤＨＣＰフレームの宛先アドレスを書き換える。この際、イーサネットヘッダにＤＨＣＰサーバのＭＡＣアドレスを、ＩＰアドレスにＤＨＣＰサーバのＩＰアドレスを設定するといった処理を行う。また、チェックサムなど、その他のフィールドも必要に応じて書き換える。
（５）ステップＳ１０５
一方、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されていないと判断した場合、アクセス先登録要求処理を起動する。
【００４８】
上記の処理の後に、フレームを宛先に送信する。ここで、ステップＳ１０１乃至Ｓ１０３の確認順序は処理性能を勘案し、適宜変更することが可能である。
【００４９】
図１０を参照して、アクセス先登録要求処理のフローを説明する。
（１）ステップＳ２１１
仮想マシンモニタ１１０は、図６のステップＳ１０５でアクセス先登録要求処理を起動すると、ＤＨＣＰのブロードキャストを要求した仮想マシン１２０−１にアクセス先登録要求を行う。
（２）ステップＳ２２１
アクセス先登録要求を受信した仮想マシン１２０−１は、アクセス先登録要求があったことをマークする。
（３）ステップＳ２２２
その後、仮想マシン１２０−１は、ＤＨＣＰサーバからＤＨＣＰＡＣＫを受信することで、ＤＨＣＰサーバが確定することになるが、この後、アクセス先登録要求がマークされているか否かを確認する。
（４）ステップＳ２２３
マークされていると、仮想マシンモニタ１１０に、確定したＤＨＣＰサーバのアドレス情報（ＭＡＣアドレス、ＩＰアドレス）を通知する。
（５）ステップＳ２１２
仮想マシンモニタ１１０は、このアドレス情報をアクセス先記憶部１１１に格納する。ここでは、仮想マシンモニタ１１０がアドレス情報をアクセス先記憶部１１１に格納するフローを説明したが、仮想マシン１２０−１がアクセス先記憶部１１１にアクセス可能な場合は、仮想マシン１２０−１が直接アドレス情報をアクセス先記憶部１１１に格納しても良い。
【００５０】
一方、図７に示すように、仮想マシン１２０−２がＤＨＣＰサーバとして動作する場合には、仮想マシン１２０−２は、ＤＨＣＰサーバとしての機能を開始すると、アクセス先記憶部１１１へ自らのアドレス情報を登録しても良い。登録に際しては、仮想マシンモニタ１１０に登録要求し、その要求を受けた仮想マシンモニタ１１０が登録しても良い。また、アクセス先記憶部１１１へ、仮想マシン１２３が直接情報を書き込める場合には、仮想マシン１２３が直接書き込んでも良い。
【００５１】
本発明の第１実施形態では、ブロードキャストメッセージをユニキャストメッセージに書き換えるように構成されているため、ブロードキャストによるネットワーク負荷を抑えることができる。また、宛先アドレスが自物理マシン１００内の仮想マシン１２０−２である場合には、通信路２００にフレームを送出することもしないので、ネットワーク上の他のノードに影響を及ぼさない。更に、ＤＨＣＰサーバとして動作する仮想マシン１２０−２に直接フレームを送信するので、高速な通信が行える。
【００５２】
次に、本発明の第２実施形態の構成について図面を参照して詳細に説明する。
図１１を参照すると、本発明の第２実施形態の構成は、図４のアクセス先記憶部１１１として、複数のアクセス先サーバアドレスを格納できるようになっている。
【００５３】
次に、図１２のフローチャートを参照して、本発明の第２実施形態の動作について詳細に説明する。図１２では、図８のフローチャートにＳ１０６乃至Ｓ１０８が追加されるが、その他は同じである。
（１）ステップＳ１０１
仮想マシン１２０−１から送信されたフレームをフレーム受信部１１２で受信すると、そのフレームが、ブロードキャストフレームかを確認する。この確認には、図９に示すようなＤＨＣＰメッセージフォーマットにおいて、宛先アドレスがブロードキャストアドレスかどうかで判断する。
（２）ステップＳ１０２
このフレームがブロードキャストフレームの場合、フレーム書換部１１３は、このフレームがＤＨＣＰメッセージかを確認する。
（３）ステップＳ１０３
このフレームがＤＨＣＰメッセージである場合、フレーム書換部１１３は、アクセス先記憶部１１１を参照し、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されているかを確認する。
（４）ステップＳ１０５
フレーム書換部１１３は、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されていないと判断した場合、アクセス先登録要求処理を起動する。
（５）ステップＳ１０６
フレーム書換部１１３は、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されている場合、ＤＨＣＰサーバのアドレス情報が複数格納されているかを確認する。
（６）ステップＳ１０４
フレーム書換部１１３は、ＤＨＣＰサーバのアドレス情報が複数格納されていない場合、すなわちＤＨＣＰサーバのアドレス情報が１つだけの場合、格納されているＤＨＣＰサーバのアドレス情報でＤＨＣＰフレームの宛先アドレスを書き換える。この際、イーサネットヘッダにＤＨＣＰサーバのＭＡＣアドレスを、ＩＰアドレスにＤＨＣＰサーバのＩＰアドレスを設定するといった処理を行う。また、チェックサムなど、その他のフィールドも必要に応じて書き換える。
（７）ステップＳ１０７
フレーム書換部１１３は、ＤＨＣＰサーバのアドレス情報が複数格納されている場合、格納されているＤＨＣＰサーバ数に応じてバッファサイズを決定し、少なくとも一つのユニキャスト用フレームバッファのアロケートを行う。
（８）ステップＳ１０８
そして、フレーム書換部１１３は、フレーム受信部１１２で受信したフレームと、ＤＨＣＰサーバのアドレス情報に基づいて、それらＤＨＣＰサーバを宛先とするように、アロケートしたバッファに少なくとも一つのユニキャスト用フレームを作成する。作成されたユニキャスト用フレームをフレーム送信部１１４で送信する。
【００５４】
本発明の第２実施形態では、複数のＤＨＣＰサーバを登録し、ＤＨＣＰメッセージを送信できるように構成されているため、いずれかのＤＨＣＰサーバが障害でダウンしたり、メンテナンスのために使用ができなくなっても、残りのＤＨＣＰサーバを使ってＤＨＣＰ処理を行うことができる。
【００５５】
次に、本発明の第３実施形態の構成について図面を参照して詳細に説明する。
図１３を参照すると、アクセス先記憶部１１１は、ＤＨＣＰサーバのアドレス情報を格納した格納時刻もあわせて記録する。図１４を参照すると、第３実施形態のフレーム書換部１１３は、図８のフローチャートに加え、ステップＳ１０９が追加されている。
（１）ステップＳ１０１
仮想マシン１２０−１から送信されたフレームをフレーム受信部１１２で受信すると、そのフレームが、ブロードキャストフレームかを確認する。この確認には、図９に示すようなＤＨＣＰメッセージフォーマットにおいて、宛先アドレスがブロードキャストアドレスかどうかで判断する。
（２）ステップＳ１０２
このフレームがブロードキャストフレームの場合、フレーム書換部１１３は、このフレームがＤＨＣＰメッセージかを確認する。
（３）ステップＳ１０９
フレーム書換部１１３は、このフレームがＤＨＣＰメッセージであると判断した場合でも、ＤＨＣＰサーバのアドレス情報を格納した時刻から所定時刻が経過した場合は、ブロードキャストのままとする。そして、アクセス先登録要求処理を起動する。
（４）ステップＳ１０３
フレーム書換部１１３は、このフレームがＤＨＣＰメッセージであり、且つ、ＤＨＣＰサーバのアドレス情報を格納した時刻から所定時刻が経過していない場合、フレーム書換部１１３は、アクセス先記憶部１１１を参照し、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されているかを確認する。
（５）ステップＳ１０４
ＤＨＣＰサーバのアドレス情報が格納されている場合、フレーム書換部１１３は、格納されているＤＨＣＰサーバのアドレス情報でＤＨＣＰフレームの宛先アドレスを書き換える。この際、イーサネットヘッダにＤＨＣＰサーバのＭＡＣアドレスを、ＩＰアドレスにＤＨＣＰサーバのＩＰアドレスを設定するといった処理を行う。また、チェックサムなど、その他のフィールドも必要に応じて書き換える。
（６）ステップＳ１０５
一方、アクセス先アドレスとしてＤＨＣＰサーバのアドレス情報が格納されていないと判断した場合、アクセス先登録要求処理を起動する。
【００５６】
本発明の第３実施形態では、一定時間毎にブロードキャストを送出することになるので、ＤＨＣＰサーバの構成が変更になっても、ブロードキャストを送出するタイミングでその変更を把握することができる。
【００５７】
次に、本発明の第４実施形態の構成について図面を参照して詳細に説明する。第４実施形態は、ＡＲＰのブロードキャスト処理についてである。
【００５８】
図１５を参照するとアクセス先記憶部１１１は、ＩＰアドレスとそれに対応するＭＡＣアドレスを格納できるようなテープルになっている。
（１）ステップＳ１０１
図１６を参照すると、仮想マシン１２０−１から送信されたフレームをフレーム受信部１１２で受信すると、そのフレームが、ブロードキャストフレームかを確認する。この確認には、図９に示すようなＤＨＣＰメッセージフォーマットにおいて、宛先アドレスがブロードキャストアドレスかどうかで判断する。
（２）ステップＳ１０２´
第４実施形態のフレーム書換部１１３は、ブロードキャストフレームであった場合、そのフレームがＡＲＰかどうかを検査する。
（３）ステップＳ１０３´
フレーム書換部１１３は、ＡＲＰであった場合、アクセス先記憶部１１１に、問い合わせようとするＩＰアドレスのＭＡＣアドレスが既に記憶されているか検査する。
（４）ステップＳ１０４´
既に記憶されていれば、フレーム書換部１１３は、そのＭＡＣアドレスでブロードキャストフレームの宛先アドレスを書き換える。
（５）ステップＳ１０５´
一方、問い合わせようとするＩＰアドレスのＭＡＣアドレスが記憶されていない場合、フレーム書換部１１３は、ＡＲＰブロードキャストフレームを送信した仮想マシンに対するアクセス先登録要求処理を起動する。
【００５９】
図１７を参照して、アクセス先登録要求処理のフローを説明する。
（１）ステップＳ２１１´
仮想マシンモニタ１１０は、図１６のＳ１０５´でアクセス先登録要求処理を起動すると、ＡＲＰブロードキャストを要求した仮想マシン１２０−１にアクセス先登録要求を行う。
（２）ステップＳ２２１´
アクセス先登録要求を受信した仮想マシン１２０−１は、アクセス先登録要求があったことをマークする。
（３）ステップＳ２２２´
その後、仮想マシン１２０−１は、問い合わせたＩＰアドレス１に一致するホストからＭＡＣアドレス１を受信するが、この後、アクセス先登録要求がマークされているか否かを確認する。
（４）ステップＳ２２３´
マークされていると、仮想マシンモニタ１１０に、ＩＰアドレスとＭＡＣアドレスとを通知する。
（５）ステップＳ２１２´
仮想マシンモニタ１１０は、このアドレス情報をアクセス先記憶部１１１に格納する。この場合、実施例１と同様に、アクセス先記憶部１１１への格納に際しては、仮想マシンモニタ１１０に登録要求し、その要求を受けた仮想マシンモニタ１１０が登録するフローを説明したが、アクセス先記憶部１１１へ、仮想マシン１２０−１が直接情報を書き込める場合には、仮想マシン１２０−１が直接書き込んでも良い。
【００６０】
本発明の第４実施形態では、ＡＲＰの場合でもブロードキャストを抑制し、ネットワーク負荷を抑えることが可能である。
【００６１】
次に、本発明の第５実施形態の構成について図面を参照して詳細に説明する。上記は、ＤＨＣＰとＡＲＰそれぞれ単独の実施形態であったが、第５実施形態では、ＤＨＣＰ、ＡＲＰの双方を同時に扱うものである。
【００６２】
図１８を参照すると、アクセス先記憶部１１１は、ポインターテーブル１１１０と、サービスアクセステーブル１１１１と、サービスアクセステーブル１１１２を有する。
ポインターテーブル１１１０は、サービスアクセステーブル１１１１及びサービスアクセステーブル１１１２へのポインターを格納する。サービスアクセステーブル１１１１及びサービスアクセステーブル１１１２は、それぞれのサービス（ＡＲＰ、ＤＨＣＰなど）のアクセス先を記憶する。また、サービスアクセステーブル１１１１及びサービスアクセステーブル１１１２は、サービスの種類を識別する情報もあわせて格納する。
【００６３】
図１９を参照して、本発明の第５実施形態の動作について説明する。
（１）ステップＳ３０１
仮想マシン１２０−１から送信されたフレームをフレーム受信部１１２で受信すると、そのフレームが、ブロードキャストフレームかを確認する。
（２）ステップＳ３０２
そのフレームがブロードキャストフレームであった場合、フレーム書換部１１３は、ｉに１を設定する。
（３）ステップＳ３０３
フレーム書換部１１３は、ポインターテーブル１１１０のサービスｉのテーブルポインターがＮＵＬＬかどうかを検査し、サービスｉのテーブルポインターがＮＵＬＬであれば、処理を終了する。
（４）ステップＳ３０４
フレーム書換部１１３は、サービスｉのテーブルポインターがＮＵＬＬでなければ、サービスｉのアクセス処理を行うが、その内容は、ＤＨＣＰやＡＲＰに応じたものであり、上述した実施例１乃至４に準じたもので良い。
（５）ステップＳ３０５
その後、フレーム書換部１１３は、ｉに１を加算し、サービスｉのテーブルポインターがＮＵＬＬかどうかの検査を行う。
【００６４】
本発明の第５実施形態では、複数のサービスについて、ブロードキャストを抑制するための処理を行うことができるので、ネットワークの負荷をより抑えることができる。
【００６５】
更に、本発明によれば、仮想マシンからブロードキャストによって宛先を探索する処理に対して、広く適用することができる。
【００６６】
なお、実際には、仮想マシン１２０は、ＶＭ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ）に限定されない。仮想マシン１２０を物理マシンに置き換えても、本発明は実施可能である。
すなわち、仮想マシン１２０は、物理マシン１００内に設置された小規模の物理マシン又は機能ブロックでも良い。例えば、図４の物理マシン１００を、フレームを送出する処理部と、この処理部から送出されたフレームを監視する監視部とを備えるコンピュータとしても本発明を実施することが可能である。この場合、処理部が仮想マシン１２０に相当し、監視部が仮想マシンモニタ１１０に相当する。
なお、物理マシン１００は、単体のコンピュータ端末に限らず、複数の端末を有するＬＡＮ等のネットワークシステムでも良い。物理マシン１００がネットワークシステムの場合、仮想マシン１２０をシステム内の端末、仮想マシンモニタ１１０を端末の監視装置又は中継装置として本発明を実施することが考えられる。この時、仮想マシン１２０に相当する端末が、物理マシン１００内で仮想マシン１２０としての動作を開始した場合、「仮想マシン１２０が生成された」ものとして扱う。同様に、端末が仮想マシン１２０としての動作を終了した場合、「仮想マシン１２０が消滅した」ものとして扱う。
【００６７】
図２０に、上記の例の場合の本発明の構成図を示す。この時、本発明の通信負荷低減装置は、システム５００と、通信路２００と、ホスト３００とを備えている。システム５００は、端末監視装置又は中継装置５１０と、端末５２０とを備えている。システム５００は物理マシン１００、端末監視装置又は中継装置５１０は仮想マシンモニタ１１０、端末５２０は仮想マシン１２０にそれぞれ該当する。この場合、端末監視装置又は中継装置５１０は、スイッチ又はルータであり、宛先情報を記憶して、必要なフレームには書き換えを行う。
【００６８】
最後に、本発明の特徴について詳述する。
本発明の通信負荷低減装置及び方法では、ＶＭを利用して複数台のクライアントを統合した環境（ハイパーバイザ）において、ＤＨＣＰサーバは同じハイパーバイザ上のＶＭに起動している。同一ＬＡＮ上には、他のクライアントや他のＤＨＣＰサーバが存在している。
【００６９】
本発明の通信負荷低減装置及び方法では、以下の点に特徴がある。
（１）ＶＭ上でクライアントが起動する。
（２）ＶＭ上のクライアントは、ＤＨＣＰ要求をローカルブロードキャストすることでＩＰアドレスを要求する。
（３）ハイパーバイザは、ＤＨＣＰのローカルブロードキャストを、ＶＭ上のＤＨＣＰサーバに送信する。
（４）ＶＭ上のＤＨＣＰサーバは、ユニキャストによりＶＭ上のクライアントにＩＰアドレスを配付する。
（５）ハイパーバイザは、ＩＰアドレスを付与されたＶＭ上のクライアントをＬＡＮに接続した状態とする。
（６）ＶＭ上のクライアントが異常終了して、ＩＰアドレスを正しく解放しない場合、ハイパーバイザは代わりに、ＤＨＣＰサーバに対して、ＤＨＣＰアドレス解放を送信する。
（７）ＬＡＮ上のＰＣがローカルブロードキャストしたＤＨＣＰ要求は、ハイパーバイザはその上の各ＶＭ群には送信しない。
（８）その他、クライアントがブロードキャストによりサービスを要求するような場合、ＤＨＣＰサーバの場合と同様に、そのサービスを行うサーバを同じハイパーバイザのＶＭ上で動作せせることで、ブロードキャストをユニキャストに置き換える。
【００７０】
以上のように、本発明は、仮想マシンからのブロードキャストの抑制である。このため、物理マシン上にある仮想マシンからブロードキャストで処理要求をする場合に、予めサービス要求先ホストが決定している場合は、当該ブロードキャストを当該ホストへのユニキャストに変更する。
【図面の簡単な説明】
【００７１】
【図１】図１は、ＤＨＣＰメッセージの例である。
【図２】図２は、ＤＨＣＰ要求処理のフローチャートである。
【図３】図３は、ＡＲＰにおけるブロードキャスト処理のフローチャートである。
【図４】図４は、本発明の通信負荷低減装置の構成を示すブロック図である。
【図５】図５は、フレームのフォーマットの例である。
【図６】図６は、通信路にフレームを送出する際の例である。
【図７】図７は、宛先アドレスを有する仮想マシンに直接送信する際の例である。
【図８】図８は、本発明の第１実施形態の動作を示すフローチャートである。
【図９】図９は、ＤＨＣＰメッセージフォーマットの例である。
【図１０】図１０は、アクセス先登録要求処理のフローチャートである。
【図１１】図１１は、本発明の第２のアクセス先記憶部の例である。
【図１２】図１２は、本発明の第２実施形態の動作を示すフローチャートである。
【図１３】図１３は、本発明の第３のアクセス先記憶部の例である。
【図１４】図１４は、本発明の第３実施形態の動作を示すフローチャートである。
【図１５】図１５は、本発明の第４のアクセス先記憶部の例である。
【図１６】図１６は、本発明の第４実施形態の動作を示すフローチャートである。
【図１７】図１７は、アクセス先登録要求処理のフローチャートである。
【図１８】図１８は、本発明の第５のアクセス先記憶部の例である。
【図１９】図１９は、本発明の第５実施形態の動作を示すフローチャートである。
【図２０】図２０は、本発明の他の通信負荷低減装置の構成を示すブロック図である。
【符号の説明】
【００７２】
１００…  物理マシン
１１０…  仮想マシンモニタ
１１１…  アクセス先記憶部
１１１０…  ポインターテーブル
１１１１…  サービスアクセステーブル
１１１２…  サービスアクセステーブル
１１２…  フレーム受信部
１１３…  フレーム書換部
１１４…  フレーム送信部
１２０（−ｋ、ｋ＝１〜ｎ（ｎは１より大きい自然数））…  仮想マシン
２００…  通信路
３００…  ホスト
５００…  システム
５１０…  端末監視装置又は中継装置
５１１…  アクセス先記憶部
５１２…  フレーム受信部
５１３…  フレーム書換部
５１４…  フレーム送信部
５２０（−ｋ、ｋ＝１〜ｎ（ｎは１より大きい自然数））…  端末
【図１】
2008028914.tif 000003
【図２】
2008028914.tif 000004
【図３】
2008028914.tif 000005
【図４】
2008028914.tif 000006
【図５】
2008028914.tif 000007
【図６】
2008028914.tif 000008
【図７】
2008028914.tif 000009
【図８】
2008028914.tif 000010
【図９】
2008028914.tif 000011
【図１０】
2008028914.tif 000012
【図１１】
2008028914.tif 000013
【図１２】
2008028914.tif 000014
【図１３】
2008028914.tif 000015
【図１４】
2008028914.tif 000016
【図１５】
2008028914.tif 000017
【図１６】
2008028914.tif 000018
【図１７】
2008028914.tif 000019
【図１８】
2008028914.tif 000020
【図１９】
2008028914.tif 000021
【図２０】
2008028914.tif 000022