以下に、本発明の実施の形態について図面を参照して説明する。
本発明は、ネットワークのリンクの帯域使用率を測定するのに適用できる。以下に説明する本発明は、通信経路中のエンドホストと各ノード間でPing を送り、エンドホストと各ノード間のRTTの遅延時間の確率密度関数を得て、逆畳みこみを利用することで、リンクの帯域使用率を推定する。
Pingとは、ネットワーク上の所定のノードに対する応答要求(Request パケット)を送り、要求に対して当該ノードが応答確認(Replyパケット)を返す一連の動作のことである。以下の説明においては、Pingを用いた方式を例にあげて説明するが、所定のノードに対して、パケットを送信し、その送信に対応した応答を受信する仕組みであれば、本発明に適用できるため、本発明の適用範囲が、IP ネットワークにおけるPing に限定されることを意味するわけではない。
パケットとは、2点間のホストで通信を行うためのデータの転送単位のことであるとする。ここでは、パケットとの記載をするが、本発明に適用できるのは、ネットワークにおけるパケットだけではなく、そのようなパケットだけに限定されることを意味する記載ではない。RTTは、送信側のエンドホストが、Request パケットを送ってから、Replyパケットを受信するまでの時間である。
ネットワークのリンクの帯域使用率について説明する。まず、ネットワークとして、図1に示したようなネットワークを例にあげて説明する。図1に示したネットワークは、エンドホスト11がノード12と接続され、ノード12がエンドホスト13と接続されている。ノード12は、キュー21を備える。このようなネットワークにおいて、エンドホスト11からエンドホスト13に至る通信経路には、1つのノード12しか存在しておらず、このようなネットワークを1ホップからなる通信経路と称する。
1ホップからなる通信経路においては、RTTの遅延時間は、ノード12で起こることになる。すなわち、RTTは、次式(1)で表すことができる。
RTT=Const+Tque ・・・(1)
式(1)において、Constは、次式(2)で表される値であり、Tqueは、キュー21におけるキューイング遅延である。このキューイング遅延とは、出力インタフェースであるキュー21に、パケットが格納されている時間である。
Const=Ttrs+Tfw+Tprop ・・・(2)
式(2)において、Ttrsは処理遅延を表し、Tfwは転送遅延を表し、Tpropは伝搬遅延を表す。これらのTtrs、Tfw、Tpropは、ノード12の処理能力などに依存し、ノード固有の値となる。よって、Const、すなわち、constant(一定値)は、通信経路固有の値となる。
式(1)において、Constが一定値であるとすると、RTTの変動に係わってくるのは、Tqueということになる。このTqueは、上記したように、キュー21におけるキューイング遅延である。RTTが小さくなるのは、キューイング遅延が小さいときであり、RTTが大きくなるのは、キューイング遅延が大きいときである。すなわち、RTTの最小値RTTminは、ノード12のキュー21にパケットがないときに観測され、このとき、リンクの使用率は0となる。また、RTTの最小値RTTmin以外のRTTotherは、ノード12のキュー21にパケットがあるときであり、このときのリンクの使用率は1である。
所定の時刻におけるRTTminとRTTotherが測定された回数を、それぞれNminとNotherとした場合、帯域使用率Uは、次式(3)で表される。
帯域使用率U=Nother/(Nmin+Nother) ・・・(3)
遅延時間の確率密度関数における、最小値の出現確率が、そのリンクの使用できる帯域率Aとなる。すなわち、使用できる帯域率Aと帯域使用率Uの関係は次式(4)となる。
U=1−A ・・・(4)
図1に示したように、1ホップの通信経路の場合、エンドホスト11とエンドホスト13の2点間の通信経路における帯域使用率は、1ホップ、すなわち、ノード12の影響のみを考慮すれば良く、上記したようにして、帯域使用率Uなどを求めることができる。しかしながら、通常、図2に示すように、エンドホストからエンドホストまでの間には、複数のノードが存在し、複数のリンクが存在することになる。
図2に示したネットワークには、エンドホスト111とエンドホスト113との2点間を結ぶ通信経路上に、ノード112−1乃至112−Nが存在している。また、ノード112−1とノード112−2は、直接接続されているととともに、ノード131−1を介しても接続されている。また各ノードは、キュー121−1乃至121−N,141−1を備えている。以下の説明において、ノード112−1乃至112−Nを個々に区別する必要がない場合、単にノード112(ノード131−1も含む)と記載する。他の記載も同様に記載する。
図2に示したネットワークには、複数のノード112が存在し、複数のリンクが存在する。このような場合、RTTは、各ノード112のキューイング遅延の影響を受けることになる。そして、エンドホスト111とエンドホスト113との2点間のRTT、すなわち通信経路全体の遅延時間の確率密度関数の最小値の出現頻度は、各リンクにおける遅延時間の確率密度関数の最小値の出現頻度の積となる。エンドホスト111とエンドホスト113との2点間のRTTは求めることができ、帯域使用率を推定することはできるが、個々のリンクの帯域使用率を推定することができない。
個々のリンクの帯域使用率を推定できないと効率の良い通信経路を推定することができない。例えば、ノード112−1とノード112−2の間のリンク(リンクAとする)の帯域使用率が高く、ノード112−1からノード131−1を介してノード112−2へ行く経路のリンク(リンクBとする)の帯域使用率が低いような場合を考える。このような場合、リンクAが選択されて通信が行われるよりも、リンクBが選択されて通信が行われる方が、効率的に通信を行えるが、リンクAとリンクBの帯域使用率をそれぞれ別個に推定できないため、リンクAが選択されて通信が行われる可能性がある。効率的に通信が行われるようにするためには、個々のリンクの帯域使用率を推定できることが好ましい。
そこで、以下に説明するように帯域使用率を推定することで、個々のリンクの帯域使用率を推定することを可能とする。ここでは、図2に示したネットワークモデルのうち、図3に示したネットワークモデルを例にあげ、個々のリンクの帯域使用率の推定について説明を加える。図3に示したネットワークモデルは、エンドホスト111、ノード112−1乃至112−3から構成されている。
図3に示したネットワークモデルにおいては、エンドホスト111からノード112−1を介してノード112−2へのリンクと、ノード112−2からノード112−3へのリンクが存在している。エンドホスト111とノード112−2のリンクの遅延時間の確率密度関数をf(x)とし、ノード112−2とノード112−3のリンクの遅延時間の確率密度関数をg(x)とした場合、この2つのリンクを通過するエンドホスト111とノード112−3における遅延時間の確率密度関数は、h(x)となり、このh(x)は、次式(5)で表すことができる。
式(5)より、確率密度関数h(x)は、確率密度関数f(x)と確率密度関数g(x)との畳み込み演算により算出できることがわかる。さらに、離散値定義される関数の場合、式(5)のように積分ではなく、次式(6)に示すような総和で定義することができる。
式(6)を、具体的に記載すると、以下のようになる。
h(0) = f(0)g(0) ・・・(7−1)
h(1) = f(0)g(1) + f(1)g(0) ・・・(7−2)
h(2) = f(0)g(2) + f(1)g(1) + f(2)g(0) ・・・(7−3)
h(3) = f(0)g(3) + f(1)g(2) + f(2)g(1) + f(3)g(0) ・・・(7−4)
・・・・・
h(n) = f(0)g(n) + f(1)g(n-1) +・・・+ f(n-1)g(1) + f(n)g(0) ・・・(7―n)
ここで、再度図3を参照する。エンドホスト111が、図3に示したネットワークの帯域使用率を推定する場合を考える。確率密度関数f(x)は、エンドホスト111を一方のエンドホストとし、ノード112-2を他方のエンドホストとし、エンドホスト111からノード112-2に対してPingを送る(RTTを測定する)ことで求めることができる。また同様に、確率密度関数h(x)は、エンドホスト111を一方のエンドホストとし、ノード112-3を他方のエンドホストとし、エンドホスト111からノード112-2に対してPingを送る(RTTを測定する)ことで求めることができる。
しかしながら、ノード112-2を一方のエンドホストとし、ノード112-3を他方のエンドホストとし、ノード112−2とノード112−3とのリンクの確率密度関数g(x)を、エンドホスト111が求めることはできない。このことは、例えば、図2に示したネットワークモデルにおいて、エンドホスト111とエンドホスト113との2点間の通信経路上に存在するノード112のうちの所定の2台のノード112のリンクにおける確率密度関数をエンドホスト111が求めることはできないことを示している。
ここで、式(7)を再度参照する。式(7−1)を変形すると、次式(8−1)になる。
g(0)=h(0)/f(0) ・・・(8−1)
(但し、f(0)は、0ではない。他の式においても同様とする)
また、同様に、式(7−2)を変形すると、次式(8−2)になる。
g(1)=(h(1)―f(1)g(0))/f(0) ・・・(8−2)
式(8−1)から、g(0)を求めることができる。上記したように、確率密度関数f(x)と確率密度関数h(x)は、エンドホスト111からPingを送信することで推定することができるため、確率密度関数f(0)と確率密度関数h(0)は求めることができ、その求められる確率密度関数f(0)と確率密度関数h(0)を式(8−1)に代入すれば、確率密度関数g(0)を求めることができる。
また、同様に、式(8−2)から、確率密度関数g(1)を求めることができる。式(8−2)において、確率密度関数h(1)、確率密度関数f(1)、確率密度関数f(0)は、測定により求めることが可能であり、確率密度関数g(0)は、式(8−1)から求めることが可能であるため、確率密度関数g(1)も、式(8−2)から求めることが可能である。
このように、逆畳み込み演算を行うことで、所定のノード112間の確率密度関数g(x)を、エンドホスト111が求めることができる。すなわち、エンドホスト111にて、ネットワーク内の各リンクの確率密度関数g(x)を、個別に求めることができる。式(7−n)を変形することで、次式(8−n)を求めることができ、この式(8−n)から、ネットワーク内の所定のリンクnの確率密度関数g(n)を求めることができる。
このようにして、逆畳みこみ演算を行うことで推定された遅延時間の確率密度関数g(x) の最小値の統計をとることで、そのリンクで使用できる帯域率Aを推定することができる。すなわち、エンドホスト111が直接求められない遅延時間の確率密度関数g(x) は、直接求めることができる確率密度関数h(x)と確率密度関数f(x) を観測し、逆畳みこみ演算を行うことで求めることができる。このような逆畳みこみ演算を、通信経路中の全リンクに対して行うことで、全リンクの帯域使用率U(帯域率A)を推定することができ、通信経路の性能を推定することが可能となる。
ここで再度図3を参照する。エンドホスト111が、ノード112−2に対してPingを送信し、RTTを測定した場合、エンドホスト111から、ノード112−1を介してノード112−2にRequestパケットが送信される。そして、ノード112−2からノード112−1を介して、エンドホスト111にReplyパケットが送信される。RTTは、エンドホスト111において、Requestパケットを送信してからReplyパケットを受信するまでの時間である。よって、RTTには、ノード112−1において、Requestパケットが処理される時間(往路のキューイング遅延と称する)と、Replyパケットが処理される時間(復路のキューイング遅延と称する)が含まれる。
所定のノード間の確率密度関数g(x)を推定する際、往路のキューイング遅延と、復路のキューイング遅延を考慮する必要がある。例えば、往路のキューイング遅延と復路のキューイング遅延が異なるときがあるからである。ここでは特に復路のキューイング遅延を考慮した場合を説明する。
第1の実施の形態として、復路のキューイング遅延がないネットワークを考える。復路のキューイング遅延がないネットワークは、上記したようにして、確率密度関数g(x)を推定し、使用率などを推定するのに、最良の形態のネットワークである。復路のキューイング遅延がない場合、往路のキューイング遅延だけを考慮すればよいため、逆畳みこみ演算によって、復元したリンクの遅延時間の確率密度関数は往路のみのものであると仮定して処理することが可能である。よって、復元した確率密度関数の最小値の出現頻度から、そのリンクの帯域使用率を一意に推定できる。
第2の実施の形態として、復路のキューイング遅延が発生することを想定し、その復路のキューイング遅延ができるだけ発生しないように制御されることにより、復路のキューイング遅延がないネットワークと仮定して処理できるようにすることを考える。例えば、ICMP(Internet Control Message Protocol)のReplyパケットが、各ノードにおいて優先的に処理されるようにすることで実現する。通常、ノード112に受信されたパケットは、宛先アドレスに基づき次のノードの転送先が決定される。そして、そのパケットは出力インタフェースのキュー121(一時的な記憶領域)に格納される。受信されたパケットは、順次キュー121に格納されていく。
そして、電気信号もしく光信号に変換され送信されるまで、その領域に格納された状態とされる。これを通常処理もしくは通常制御と称する。仮に、パケットが大量に受信されると、このキューバッファ(キュー121)に大量のパケットが格納され、送信されるまでの遅延が生ずる。これが、上記してきたキューイング遅延となる。
一方、通常処理に対し優先処理と称する処理は、パケットヘッダに優先制御フラグが存在するパケットに対し、キュー121に格納せず、ただちに送信処理を行う処理のことである。キュー121にバッファリングされているパケットが存在しようとも、優先制御フラグがあるパケットは、ただちに送信処理されるため、キューイング遅延は発生しない状況を作り出すことができる。例えば、Replyパケットに、このような優先制御フラグを立てることで、Replyパケットは、受信されたノード112で優先的に処理されるため、復路でのキューイング遅延は発生しないことになる。
このReply パケットが優先処理に対応している状態を、ここではReply 優先モードと記述する。そして例えば、この優先制御を実現する手段としては、IPパケットヘッダにTOS(Type Of Service、優先制御するか否かのフラグを記録する領域)フィールドにフラグを立てるといったことで実現できる。または、他の手段を用いても良い。
このようなReply優先モードを設け、処理されるようにすることで、仮に、Replyパケットを受信したノード112のキュー121に、パケットが既に格納されていても、それらの格納されているパケットよりも先に処理される制御することができ、結果として、復路のキューイング遅延が無い状態にすることができる。復路のキューイング遅延が無い状態と仮定して処理することができれば、第1の実施の形態と同じく、逆畳みこみ演算によって、復元したリンクの遅延時間の確率密度関数は往路のみのものであると仮定して処理することが可能となる。よって、この場合も、復元した確率密度関数の最小値の出現頻度から、そのリンクの帯域使用率を一意に推定できる。
第3の実施の形態として、往路と復路の経路が一致し、復路にもキューイング遅延がある場合を考える。往路と復路の経路が一致するとは、例えば、図2を参照するに、エンドホスト111から、ノード112−1、ノード112−2、・・・、ノード112−Nを介して、エンドホスト113に到達する往路の経路と、エンドホスト113から、ノード112−N、・・・、ノード112−2、ノード112−1を介して、エンドホスト111に到達する復路の経路が一致している場合である。
往路と復路の経路が一致し、復路にもキューイング遅延がある場合、逆畳みこみ演算することで復元されたリンクの遅延時間の確率密度関数は、そのリンクの往路と復路の遅延時間の確率密度関数が畳み込まれたものとなる。よって、復元された遅延時間の確率密度関数の最小値の出現頻度から、リンクの帯域使用率は特定することはできない。そこで、復元された遅延時間の確率密度関数h(x)(h(x) = (f*g)(x))とし、その最小値の出現頻度h(0)=Aとする。
帯域使用率Uは、0≦ U ≦ 1 を満たすので、往路と復路における、確率密度関数の最小値の出現頻度は、
A ≦ f(0) ≦ 1
A ≦ g(0) ≦ 1
f(0)g(0)=A
の条件が満たされる。これらの条件から、往路、復路のいずれかの使用できる帯域率の最低値はAであることになる。すなわち、往路または復路の帯域使用率は、1−A を越えないということがわかる.帯域使用率は一意に推定できないが、往復路の最高の帯域使用率がわかるので、そのリンクの負荷の状況を推定することができる。
第4の実施の形態として、往路と復路の経路が一致せず、復路にもキューイング遅延がある場合を考える。往路と復路の経路が一致していない場合とは、図2に示したネットワークにおいて、往路は、ノード112−1からノード112−2にパケットが渡されたが、復路は、ノード112−2からノード131−1を介してノード112−1にパケットが渡されたような場合であり、このような経路のときには、往路と復路の経路が一致していないことになる。
第4の実施の形態においては、第3の実施の形態と同じく、特定のリンクの帯域使用率を一意に推定することは困難である。しかしながら、帯域使用率Uは、0≦ U ≦ 1 を満たし、リンクのいずれも帯域使用率Uは、1−A を越えることがない。よって、ネットワークに負荷が掛かっている箇所の特定はできるため、その負荷が掛かっている箇所を避けて通信を行うなどの制御を行うことが可能となる。
第5の実施の形態として、途中ノードのIPアドレスが不明なネットワークである場合を考える。途中ノードのIPアドレスが不明なネットワークに対して、ICMPのTrace Routeを用いることで、経路上に存在するノードのIPアドレスを特定することができる。Trace Route とは、送信元ホスト(たとえば、エンドホスト111)から指定した宛先ノード(たとえば、エンドホスト113)までの通信経路を調査することを意味する。まず送信元ホストは指定した宛先ノードまで、TTLが1のRequest パケットを送信する。TTLとは、パケットがノードを何回通過できるかの回数を表す。中継ノードにパケットが到着すると、その中継ノードにより、TTLの値が1だけ減算された値とされる。その結果、TTLの値が0になった場合、その中継ノードにより、送信元ホストに向かって宛先到達不能通知が送信されるとともに、当該パケットは破棄される。
宛先到達不能通知には、パケットを破棄した中継ノードのIPアドレスが記載されているため、そのパケットを受信した送信元ホストは、パケットを破棄した中継ノードのIPアドレスを取得することができる。このような宛先到達不能通知が受信されると、送信元ホストは、TTLを1だけ増やした値のパケットを送信する。このようにパケットを送信することで、パケットを破棄した中継ノードの次の中継ノードのIPアドレスを取得することができる。通信経路上の各中継ノードから、このような宛先到達不能通知を順次受信することで、送信元ホストは、経路上の各中継ノードのIPアドレスを取得する。なお、ここでは、Trace Routeを例にあげて説明を続けるが、通信経路上の中継ノードのIPアドレスを取得する方法が、Trace Routeに限定されることを示す記載ではなく、他の方法により、通信経路上の中継ノードのIPアドレスが取得されるような場合であっても、本発明を適用することはできる。
このように、通信経路のエンドホスト(送信元ホスト)は、もう一方のエンドホスト(宛先ノード)に向かって、TTL(初期値1)が小さいRequest パケットを複数回送信する。そして、TTLの値を1ずつ増加させるたびに複数回パケットが送信され、順次中継ノードのIPアドレスが取得される。このような処理が、宛先ノードからReply パケットが届くまで繰り返される。この処理によれば、IPアドレスの不明なネットワークにおいて、通信経路上の中継ノードのIPアドレスが取得できるだけでなく、途中ノードから、順々にTTL切れの宛先到達不能通知が送信元ホストに届くので、送信元ホストと各中継ノード間のRTTの遅延時間の確率密度関数も同時に取得できることになる。確率密度関数が取得できるので、第1の実施の形態乃至第4の実施の形態と同じく、逆畳み込み演算により、リンクの帯域使用率や負荷の状況を推定することができる。
次に、エンドホストや各中継ノードにおける処理について説明する。図4に示したネットワークモデルを用いて説明する。図4において、エンドホスト111を送信側のホスト(帯域使用率を算出するホスト)とし、エンドホスト113を最終的な宛先ノードとし、ノード112を中継ノードとする。ここで、エンドホスト113を最終的な宛先ノードと記載したのは、以下に説明するように、中継ノードが順次宛先ノードに設定されて処理され、最終的な宛先ノードがエンドホスト113であるからである。エンドホスト111は、送信処理部151と受信処理部152を備える。ノード112は、送受信処理部161を備える。エンドホスト113は、送受信処理部171を備える。
まず、図5のフローチャートを参照し、エンドホスト111が行う処理について説明する。図5のフローチャートを参照して説明するエンドホスト111が行う処理は、宛先ノードまでの通信経路上の中継ノードのIPアドレスがわかっている状態のときに行われる処理である。換言すれば、Trace Routeを用いないときの、送信側のホストが行う送信時の処理である。さらに換言すれば、第1乃至第4の実施の形態に該当するときの送信元ホストが実行する処理である。
ステップS11において、送信処理部111は、中継ノードのうち、所定のノード112を宛先ノードに設定し、そのノードのアドレスをセットする。送信側のホストであるエンドホスト111は、エンドホスト113までの通信経路上に存在するノードのアドレスを認識している。そして、その通信経路上に存在し、帯域使用率を推定したいリンクの両端のノードの全てを、順次宛先ノードに設定し、Requestパケットを送信する。そのような処理を行うため、ステップS11においては、まだRequestパケットを送信していない通信経路上のノードのうち、1つのノードが選択され、宛先ノードに設定されるという処理が行われる。また、同一の宛先ノードに複数回Requestパケットを送信するため、アドレスがセットされる。
ステップS12において、Replyパケット優先モードにするか否かが判断される。Replyパケット優先モードとは、上記したように、Replyパケットを中継ノードにおいて、他のパケットよりも優先して処理するように指示するためのモードであり、復路のキューイング遅延を考慮しなくても処理できるようにしたときなどに設定されるモードである。ステップS12において、Replyパケット優先モードにすると判断された場合、ステップS13に処理が進められ、Replyパケット優先モードにはしないと判断された場合、ステップS13の処理はスキップされ、ステップS14の処理に進められる。
ステップS13において、Requestパケットヘッダに優先制御フラグが立てられる。Requestパケットヘッダに優先制御フラグが立てられた場合、上記したように、そのRequestパケットに対するReplyパケットは、各ノードにおいて優先的に処理される。ステップS13において、Requestパケットヘッダに優先制御フラグが立てられた場合、または、ステップS12において、Replyパケット優先モードにしないと判断された場合、ステップS14に処理が進められる。ステップS14において、Requestパケットが、セットされているアドレスを有する宛先ノードに対して送信され、その送信時刻が記録される。エンドホスト111は、記憶部(不図示)を有し、送信時刻を記憶する。記憶部としては、メモリ、ハードディスクなどを用いることが可能である。
ステップS15において、所定の回数、同一の宛先ノードにRequestパケットを送信したか否かが判断される。所定の回数は、その宛先ノードに関するRTTの遅延時間の確率分布を得るのに十分な回数とされる。この所定の回数は、N回などと予め設定された固定値であっても良いし、確率分布を得るのに十分な結果が得られたと判断された時点までの回数とする可変値であっても良い。ステップS15において、所定の回数、同一の宛先ノードにRequestパケットを送信はしていないと判断された場合、ステップS12に処理が戻され、それ以降の処理が実行される。
なお、ここでは、ステップS12に処理が戻されるとして説明を続けるが、ステップS13またはステップS14に処理が戻されるようにしても良い。ステップS12に処理が戻されることで、同一の宛先ノードに対して、Requestパケット優先モードでパケットを送信したり、Requestパケット優先モードでない状態でパケットを送信したりすることができるため、例えば、x回、Requestパケット優先モードで送信し、y回、Requestパケット優先モードではないモードで送信するといった使い分けを行うことが可能となる。また、モードを変えることで、復路の影響を計測することも可能となり、計測される復路の影響を、何らかの推測に用いるといったことも可能となる。
ステップS13またはステップS14に処理が戻されるようにした場合、同一の宛先ノードには、同一のモードでRequestパケットが送信されることになる。よって、Requestパケット優先モードに設定された場合には、ステップS13に処理が戻され、Requestパケット優先モードに設定されていない場合には、ステップS14に処理が戻される。
一方、ステップS15において、所定の回数、同一の宛先ノード(中継ノード)にRequestパケットを送信したと判断された場合、ステップS16に処理が進められる。ステップS16において、通信経路上の宛先として設定したい全ノードに対して、Requestパケットを送信したか否かが判断される。宛先として設定したい全ノードとは、帯域使用率を推定したい全リンクの両端に位置するノードのことである。ステップS16において、通信経路上の宛先として設定したい全ノードに対して、Requestパケットを送信していないと判断された場合、ステップS17に処理が進められる。ステップS17において、通信経路上の中継ノードのうち、宛先ノードに設定していない中継ノードのうちの1つが選択され、その選択されたノードが新たな宛先ノードとして設定される処理が実行される。そして、新たに設定された宛先ノードに対して、ステップS12以降の処理が繰り返される。
このようにして、通信経路上の宛先として設定したい全ノードに対して、Requestパケットが、複数回送信される。エンドホスト111は、Requestパケットを送信することにより、宛先ノードからReplyパケットを受信する。この受信に関する処理および受信後に行われる処理に関して、図6のフローチャートを参照して説明する。
図6のフローチャートは、エンドホスト111(送信側のホストであり、リンクの帯域使用率などを測定するホスト)の受信処理部152が行う処理である。ステップS31において、宛先ノードに設定されているノードからReplyパケットが受信される。ステップS32において、Replyパケットの受信時刻が記録される。そして、ステップS33において、RTTが算出され、記録される。RTTが算出され、記憶されると、ステップS34において、宛先ノードが変更されたか否かが判断される。この判断は、例えば、ステップS15(図5)において、所定の回数、同一の宛先ノードにRequestパケットを送信したと判断され、ステップS16に処理が進められたとき、ステップS34において宛先ノードが変更されたと判断される。
エンドホスト111は、図5のステップS14における処理で、宛先ノードにRequestパケットを送信するため、そのRequestパケットを受信した宛先ノードから、Replyパケットを受信する。またエンドホスト111は、Requestパケットを送信した送信時刻と、そのRequestパケットに対応するReplyパケットの受信時刻を記録しているため、その送信時刻と受信時刻の差分を計算することで、RTTを算出することができる。また、同一の宛先ノードに、所定の回数、Requestパケットを送信しているため、所定の回数分だけ、同一の宛先ノードに対するRTTが算出される。複数のRTTが算出されることで、RTTの確率分布を算出することが可能な状態となる。
ステップS34において、宛先ノードが変更されたと判断された場合、ステップS35に処理が進められる。ステップS35において、RTTの遅延時間の確率分布が算出され、記録される。この処理は、その時点で処理対象とされている1つの宛先ノードに対して行われる。すなわち、ステップS31乃至S34の処理が繰り返されることで、1つの宛先ノードに対する複数のRTTが算出される。そして、その複数のRTTの度数分布が取られることで、その宛先ノードに関するRTTの遅延時間の確率分布が算出される。
ステップS36において、宛先として設定した全ての中継ノードに対するRTTの遅延時間の確率分布が算出されたか否かが判断される。通信経路上に存在する、帯域使用率を推定したいリンクの両端の全中継ノードに対して、Requestパケットが複数回送信されているため、通信経路上に存在する、帯域使用率を推定したいリンクの両端の中継ノード毎に、RTTの遅延時間の確率分布が算出される。よって、指定した全ての中継ノードのRTTの遅延時間の確率分布が算出されたか否かが、ステップS36において判断される。なお、ステップS31乃至34の処理と、ステップS35,S36の処理は、並列処理される。すなわち、ステップS31乃至S34の処理が実行されることで、所定の中継ノードに関するRTTが収集され、ステップS35,S36の処理が実行されることで、中継ノード毎のRTTの遅延時間の確率分布が算出される。
ステップS36において、指定した全ての中継ノードに対するRTTの遅延時間の確率分布が算出されたと判断された場合、ステップS37に処理が進められる。ステップS37において、逆畳み込み演算が実行され、リンク間の遅延時間の確率分布が復元される。ステップS36までの処理で、上述した確率密度関数f(x)、確率密度関数h(x)が求められているため、ステップS37においては、式(8)に基づき、確率密度関数g(x)が求められる。そして、ステップS38において、帯域使用率が推定され、記録される。そして、ステップS39において、帯域資料率を推定したい全てのリンクに対して帯域使用率が推定されたか否かが判断され、推定されていないと判断された場合、ステップS37に処理が戻され、それ以降の処理が繰り返され、推定されたと判断された場合、処理は終了される。
帯域使用率は、上記したように、帯域使用率U=1−Aで算出することができる。またAは、使用できるリンクの割合であり、RTTminから算出できる値である。所定のリンクのRTTminは、所定のリンクの確率密度関数g(x)が求められた時点で算出されており、その算出されている値を用いることができる。よって、所定のリンクにおける確率密度関数g(x)が算出されることで、所定のリンクにおける帯域使用率を算出することができる。このようにして、本発明によれば、所定のリンクの帯域使用率などを、その所定のリンク外のホストが推定することができる。
次に、中継ノードの処理について、図7のフローチャートを参照して説明する。中継ノードは、エンドホスト111とエンドホスト113との間の通信経路上に存在するノード112であり、順次、エンドホスト111により宛先ノードに設定されるノードとの間に存在するノードである。例えば、図2において、宛先ノードがノード112−Nに設定されている場合、中継ノードは、ノード112−1乃至112−N−1の各ノードとなる。ここでは、中継ノードは、ノード112(図5)であり、図7のフローチャートの処理は、ノード112の送受信処理部161が行うとして説明を続ける。また、図7のフローチャートの処理は、Trace Routeが用いられていないときの処理である。
ステップS51において、パケットを受信する。ステップS51において受信されるパケットは、RequestパケットまたはReplyパケットである。ステップS52において、受信されたパケットのパケットヘッダに、優先制御フラグがあるか否かが判断される。受信されたパケットが、Replyパケットである場合、そのReplyパケットのパケットヘッダに、Replyパケット優先モードであるときには、優先制御フラグが立てられている。よって、そのようなフラグが立てられているか否かが、ステップS52において判断される。
ステップS52において、パケットヘッダに優先制御フラグが立てられていないと判断された場合、ステップS53に処理が進められ、その受信されたパケットは、通常処理される。一方、ステップS52において、パケットヘッダに優先制御フラグが立てられていると判断された場合、ステップS54に処理が進められ、その受信されたパケットは、優先処理される。通常処理、または優先処理されたパケットは、次のノード112に対して転送される。このように、中継ノードの基本的な処理は、受信されたパケットを次のノードに転送する処理である。
次に、図8のフローチャートを参照して、宛先ノードにおける処理について説明する。宛先ノードは、エンドホスト111と宛先ノードとの間の通信経路上に存在するノード112と、エンドホスト113のうちのいずれか1つが設定される。図8のフローチャートの処理は、ノード112が宛先ノードとして設定されているときには、ノード112の送受信処理部161が実行する処理であり、エンドホスト113が宛先ノードとして設定されているときには、エンドホスト113の送受信処理部171が実行する処理である。
ステップS71において、Requestパケットが受信される。ステップS72において、受信されたRequestパケットのパケットヘッダに、優先制御フラグが立てられているか否かが判断される。ステップS72において、Requestパケットのパケットヘッダに、優先制御フラグが立てられていると判断された場合、ステップS73に処理が進められる。ステップS73において、送信されるReplyパケットのパケットヘッダに、優先制御フラグが立てられる。
ステップS73において優先制御フラグが立てられたReplyパケットは、ステップS74において、送信元ホスト、この場合、エンドホスト111に対して送信される。一方、ステップS72において、Requestパケットのパケットヘッダに、優先制御フラグは立てられていないと判断された場合、優先フラグが立てられていないReplyパケットが生成され、ステップS74において、送信元ホストに対して送信される。
このように、宛先ノードに設定されているノード112(エンドホスト113)は、受信されたRequestパケットに、優先制御フラグが立てられているときには、優先制御フラグを立てたReplyパケットを生成し、送信し、優先制御フラグが立てられていないときには、優先制御フラグを立てないReplyパケットを生成し、送信する処理を、Requestパケットを受信する毎に実行する。
上記した処理は、Trace Routeを用いていないときの送信元ホストの処理、中継ノードの処理、および宛先ノードの処理であった。次に、Trace Routeを用いていないときの送信元ホストの処理、中継ノードの処理、および宛先ノードの処理について説明する。まず、図9のフローチャートを参照し、送信元ホスト(エンドホスト111)における送信時の処理について説明する。
Trace Route が用いられる場合、通信経路中の各ノードのアドレスはわからない状態であり、一方のエンドホスト113(宛先ホスト)のアドレスはわかっている状態である。そして、そのような状態のときに、送信元ホストは、宛先ホスト(エンドホスト113)に対して,Trace Route を実行する。Trace Route が用いられない送信処理(図5のフローチャートを参照して説明した処理)では通信経路上の各ノードのアドレスが順次指定されてRequestパケットが送信されたが、Trace Routeが用いられた処理では宛先ホストのアドレスは固定され、その宛先ホストはエンドホスト113とされ、アドレスが変更されない状態でRequestパケットが送信される点が異なる。図5のフローチャートを参照して説明した処理と同一の処理については、適宜説明を省略する。
まずステップS91において、TTLの値が1に設定(初期設定)される。ステップS92において、宛先ノードのアドレスが設定される。この場合、エンドホスト113のアドレスが設定される。設定されたアドレスは、処理が終了するまで、Requestパケットの送信先のアドレスとされる。ステップS93において、Replyパケット優先モードにするか否かが判断され、優先モードにすると判断された場合、ステップS94に処理が進められ、パケットヘッダに、優先制御フラグが立てられたRequestパケットが生成され、ステップS95に処理が進められる。
一方ステップS93において、Replyパケット優先モードにしないと判断された場合、ステップS94の処理はスキップされ、ステップS95に処理が進められる。ステップS95において、Requestパケットが生成される。その生成されるRequestパケットのパケットヘッダにセットされるTTLは、その時点で設定されている値とされる。ステップS91から処理が来た場合、TTL=1に設定されているため、TTLが1に設定されたRequestパケットが生成される。
ステップS96において、生成されたRequestパケットが宛先ノードに送信され、その送信した時刻が記録される。そして、ステップS97において、所定の回数、同一のノードに対して、Requestパケットが送信されたか否かが判断される。この場合、宛先ノードは、エンドホスト113であり、固定とされているため、エンドホスト113に対してRequestパケットが送信されることになるが、TTLとして設定されている値が同一の値とされている間、エンドホスト111とエンドホスト113との2点間の通信経路上にある所定のノード112に対してRequestパケットが送信されることになる。よって、所定の回数、同一のノードに対して、Requestパケットを送信することができる。
ステップS97において、所定の回数、同一のノードに対して、Requestパケットが送信されてはいないと判断された場合、ステップS93に処理が戻され、それ以降の処理が繰り返され、送信されたと判断された場合、ステップS98に処理が進められる。ステップS93乃至S97の処理が繰り返されることにより、同一のノードに複数回、Requestパケットが送信されることになる。
ステップS98において、宛先ノードからのReplyパケットを受信したか否かが判断される。この場合、宛先ノードは、エンドホスト113であるため、エンドホスト113からのReplyパケットが受信されたか否かが判断される。なお、エンドホスト113以外のノードからのReplyパケットは、宛先到達不能通知パケットであるため、そのような宛先到達不能通知パケットではないか否かを判断することで、ステップS16の処理が行われるようにしても良い。宛先ノードからのReplyパケットは受信していないと判断されるのは、エンドホスト113にRequestパケットが到達していないときである。
ステップS98において、宛先ノードからのReplyパケットは受信していないと判断された場合、ステップS99に処理が進められ、TTLの値が1だけ増加される。ステップS99において、TTLの値が1だけ増加されると、ステップS93に処理が戻され、それ以降の処理が繰り返される。ステップS93乃至99の処理が繰り返されることにより、エンドホスト111に近い側のノードから順次、Requestパケットが複数回送信されることになる。
このようなTrace Routeが用いられて送信元ホスト(エンドホスト111)の送信に係わる処理が実行された場合、受信に係わる処理は、図6のフローチャートの処理に基づき行われる。すなわち、Trace Routeが用いられた場合と、Trace Routeが用いられていない場合とでは、送信時の処理は異なるが、受信時の処理は同一の処理とされる。すなわち、Trace Routeが用いられた場合であっても、同一のノードから、複数回、Replyパケット(宛先到達不能通知パケット)受信されるため、各ノードにおけるRTTの遅延時間に関する確率密度関数を算出することができる。よって、受信時の処理として、同一の処理を行えば、所定のリンクの帯域使用率を推定することができる。
Trace Routeが用いられた場合、中継ノードにおける処理が、Trace Routeが用いられていない場合と比較して異なる処理を含むため、次に、図10を参照して、Trace Routeが用いられたときの中継ノードの処理について説明する。中継ノードは、図4において、ノード112であり、図10のフローチャートの処理は、ノード112の送受信処理部161が行う。
ステップS111において、Requestパケットが受信される。ステップS112において、受信されたRequestパケットに含まれるTTLの値が1だけ減算された値とされる。その結果、TTLが0になったか否かがステップS113において判断される。ステップS113において、TTLが0にはなっていないと判断された場合、ステップS114に処理が進められ、受信されたパケットは、通常処理される。すなわち、ステップS115において、次ノードに転送される処理が実行される。
一方、ステップS113において、TTLは0になったと判断された場合、ステップS116に処理が進められる。ステップS116において、宛先到達不能通知パケットが生成される。ステップS117において、受信されたRequestパケットのパケットヘッダに優先制御フラグが立っているか否かが判断される。ステップS117において、優先制御フラグが立っていると判断された場合、ステップS118に処理が進められる。ステップS118において、宛先到達不能通知パケットのパケットヘッダに、優先制御フラグが立てられる。
ステップS118において、優先フラグが立てられた宛先到達不能通知パケットが生成された場合、または、ステップS117において、優先制御フラグは立てられていないと判断された場合、ステップS119において、送信元ホストに対して、宛先到達不能通知パケットが送信される。そして、宛先到達不能通知パケットが送信されたときには、受信されたRequestパケットはステップS120において破棄される。
このように、Trace Routeが適用されているときに、Requestパケットを受信した中継ノードは、TTLの値が0になったときに、宛先到達不能通知パケットを生成し、送信元ホストに送信するといった処理を行う。宛先到達不能通知パケットには、宛先到達不能通知パケットを生成した中継ノードのIPアドレスが含まれるため、そのような宛先到達不能通知パケットを受信した送信元ホストにおいては、中継ノードのIPアドレスを知ることができる。よって、宛先ノードまでの通信経路上に存在する中継ノードのIPアドレスを調べながら、RTTを得ることができ、リンク毎の帯域使用率などを推定することが可能となる。
なお、上述した説明においては、通信経路上のノードのアドレスが不明なネットワークに対して、TTLの値を順次増やすことで、IPアドレスを順次調べ、同一の値のTTLを複数回送信することで、RTTの確率密度関数を求め、所定のリンクの帯域使用率を求めるとして説明した。
他の実施の形態として、通信経路上のノードのIPアドレスが不明なネットワークに対して、上記したようにTTLの値を順次増やすことで、中継ノードのIPアドレスを順次調べ、経路上の全てのノードのIPアドレスを調べ終わった後に、その調べ上げたIPアドレスを用いて、IPアドレスがわかっているネットワークに対する処理、すなわち、図5乃至図8のフローチャートの処理がホストやノードにおいて行われることで、RTTの確率密度関数が求められ、所定のリンクの帯域使用率が求められるようにしても良い。
本発明を適用することで、Ping をエンドホストや通信経路上に存在する各ノードに送るという簡便な処理だけで、各ノードに対するRTTの遅延時間の確率密度関数が取得でき、それを逆畳み込み演算することで、通信経路中の各リンクの帯域使用率を推定することができる。すなわち、本発明によれば、Pingという簡便なものを用いて、通信経路中の各リンクの帯域使用率を推定することができる。
[記録媒体について]
上述した一連の処理は、ハードウエアにより実行することもできるし、ソフトウエアにより実行することもできる。一連の処理をソフトウエアにより実行する場合には、そのソフトウエアを構成するプログラムが、コンピュータにインストールされる。ここで、コンピュータには、専用のハードウエアに組み込まれているコンピュータや、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどが含まれる。
図11は、上述した一連の処理をプログラムにより実行するコンピュータのハードウエアの構成例を示すブロック図である。コンピュータにおいて、CPU(Central Processing Unit)201、ROM(Read Only Memory)202、RAM(Random Access Memory)203は、バス204により相互に接続されている。バス204には、さらに、入出力インタフェース205が接続されている。入出力インタフェース205には、入力部206、出力部207、記憶部208、通信部209、およびドライブ210が接続されている。
入力部206は、キーボード、マウス、マイクロフォンなどよりなる。出力部207は、ディスプレイ、スピーカなどよりなる。記憶部208は、ハードディスクや不揮発性のメモリなどよりなる。通信部209は、ネットワークインタフェースなどよりなる。ドライブ210は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどのリムーバブルメディア211を駆動する。
以上のように構成されるコンピュータでは、CPU201が、例えば、記憶部208に記憶されているプログラムを、入出力インタフェース205およびバス204を介して、RAM203にロードして実行することにより、上述した一連の処理が行われる。
コンピュータ(CPU201)が実行するプログラムは、例えば、パッケージメディア等としてのリムーバブルメディア211に記録して提供することができる。また、プログラムは、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の伝送媒体を介して提供することができる。
コンピュータでは、プログラムは、リムーバブルメディア211をドライブ210に装着することにより、入出力インタフェース205を介して、記憶部208にインストールすることができる。また、プログラムは、有線または無線の伝送媒体を介して、通信部209で受信し、記憶部208にインストールすることができる。その他、プログラムは、ROM202や記憶部208に、予めインストールしておくことができる。
なお、コンピュータが実行するプログラムは、本明細書で説明する順序に沿って時系列に処理が行われるプログラムであっても良いし、並列に、あるいは呼び出しが行われたとき等の必要なタイミングで処理が行われるプログラムであっても良い。
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
なお、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。