ネットワークにおけるデータ圧縮の効果を考慮したパス設定方法
【課題】データ圧縮・伸長機能を有するネットワーク機器がネットワークに含まれていても、そのデータ圧縮の効果を考慮してネットワークを適切に表現し、最適パスを設定可能にすること。
【解決手段】データ圧縮・伸長機能を有するネットワーク機器を含むノード14,15は、自ノードに接続されたリンク21,23の伝送遅延およびデータ圧縮処理による処理遅延の和を当該リンク21,23についての遅延として算出し、該遅延を当該リンク21,23のメトリックとする。ルータを含むノード11〜13は、自ノードに接続されたリンク21〜25の伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンク21〜25のメトリックとする。ノード11〜15は、各リンク21〜25のメトリックを共有し、該メトリックを元に最適パスを設定する。
【解決手段】データ圧縮・伸長機能を有するネットワーク機器を含むノード14,15は、自ノードに接続されたリンク21,23の伝送遅延およびデータ圧縮処理による処理遅延の和を当該リンク21,23についての遅延として算出し、該遅延を当該リンク21,23のメトリックとする。ルータを含むノード11〜13は、自ノードに接続されたリンク21〜25の伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンク21〜25のメトリックとする。ノード11〜15は、各リンク21〜25のメトリックを共有し、該メトリックを元に最適パスを設定する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークにおけるデータ圧縮の効果を考慮したパス設定方法に関し、特に、WAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器がネットワークに含まれていても、ネットワーク機器でのデータ圧縮の効果を考慮してネットワークを管理することができ、最適パスを設定することができるパス設定方法に関する。
【背景技術】
【０００２】
従来のネットワークでは、ネットワークを構成する各リンクの帯域情報(空き帯域量)を元に最適パスを設定する。このために、ネットワーク内の各ノード(ルータ)は、自ノードに接続されている各リンクの帯域情報を求めて格納すると共に該帯域情報をネットワークに広告し、また、他ノードから広告された帯域情報を格納する。ネットワーク内の各ノードは、ネットワークの帯域情報を共有し、該帯域情報を元に最適パスを設定することができる。非特許文献１，２には、このようなネットワーク管理技術の標準化について記載されている。
【０００３】
近年、従来のルータに加えてWAN(wide area network)高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器(以下では、WAN高速化装置と称する。)がネットワーク内に部分的に配置されるケースがでてきている。WAN高速化装置については、非特許文献３に記載されている。
【０００４】
図４は、WAN高速化装置が部分的に配置されたネットワークを模式的に示すブロック図である。ここでは、ルータ11〜13、WAN高速化装置14，15をリンク21〜25で接続して構成されたネットワーク10を示している。WAN高速化装置14、15は、リンク21、23に接続されている。ユーザ31、33は、データ圧縮を利用するが、ユーザ32、34は、データ圧縮を利用しない。
【０００５】
ネットワーク内にWAN高速化装置が含まれている場合、WAN高速化装置を通して転送されるデータは、そこで圧縮/伸張される。WAN高速化装置は、ネットワークにおける適宜のユーザ側端に配置され、各WAN高速化装置が提供するデータ圧縮率も様々である。このことは、従来のようにリンクの帯域情報でネットワークを適切に表現することを妨げ、したがって、ネットワークを適切に管理することを妨げている。その理由は、後述する。
【０００６】
このように、従来の技術では、WAN高速化装置でのデータ圧縮の効果をデータ伝送上でのネットワークにおける距離、すなわち、「メトリック」として適切に表現することができず、結果として、WAN高速化装置でのデータ圧縮の効果を無視してネットワークを管理せざるを得ない。なお、「メトリック」は、「データ伝送上でのネットワークにおける距離」を表す専門用語であり、メトリックの値が小さくなる程、ネットワークにおけるデータ伝送上の距離が短くなって通信コストが低いことを示す。すなわち、「メトリック」の値は、通信コストを表す。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】RFC3630(Traffic Engineering (TE) Extensions to OSPF Version 2)
【非特許文献２】RFC53058(IS-IS Extensions for Traffic Engineering)
【非特許文献３】WAN高速化(http://www.cisco.com/web/JP/news/cisco_news _letter/ tech/waas2/index.html)
【非特許文献４】M. Shimamura, H. Koga, T. Ikenaga, and M. Tsuru, "Compressing packets adaptively inside networks," IEICE Transactions on Communications, vol. E93-B, no. 3, pp. 501-515, March 2010.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
WAN高速化装置でのデータ圧縮は、リンクの帯域量を実効的に増加させる効果をもたらす。したがって、従来の技術と同様に、リンクの帯域情報をメトリックとして表現してネットワークを管理することが考えられる。具体的には、従来では、RFC3630などOSPF(open shortest path fast)プロトコルが利用されているので、WAN高速化装置にOSPFを適用する方法が考えられる。
【０００９】
しかし、リンクの帯域情報によりネットワークを管理する方法では、例えば、図４のリンク21やリンク23のみ見かけの帯域量を大きくして広告する、というだけでは意味をなさない。すなわち、WAN高速化は、データ圧縮側とデータ伸長側が対となって始めて機能するというエンドツーエンドで機能するという特徴を有し、このため、データ圧縮側とデータ伸長側のWAN高速化装置によって処理されるデータが経由する経路を構成する全てのリンクの帯域量を、WAN高速化装置でのデータ圧縮を考慮した値にする必要がある。
【００１０】
例えば、図４では、リンク22、あるいはリンク24、25についてルータ11 〜13が広告するリンクの帯域量をWAN高速化装置14(あるいはWAN高速化装置15)でのデータ圧縮に応じて変更する必要がでてくる。
【００１１】
実際のネットワークでは、対となるWAN高速化装置の間にはルータが存在することが多く、ルータは、WAN高速化装置とは独立に動作していて、WAN高速化装置でのデータ圧縮に呼応してデータ圧縮する訳ではない。したがって、WAN高速化装置でのデータ圧縮に応じて、それに接続されているリンクのみの帯域量の変動を広告しても、それ以外のリンクの帯域量は不変とされるので、ネットワークが適切に表現されず、適切に管理されないことになる。
【００１２】
また、WAN高速化装置が何対も配置されるケースや、WAN高速化装置でのデータ圧縮が施されないユーザ(図４のユーザ32、34)のトラヒックもあることを考えると、仮にWAN高速化装置にOSPFを実装したとしても問題の解決は困難である。つまり、WAN高速化装置でのデータ圧縮の効果をリンクの帯域情報で表現してネットワークを管理しようとすることには、多くの困難がある。
【００１３】
本発明の目的は、上記課題を解決し、WAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器がネットワークに含まれていても、ネットワーク機器でのデータ圧縮の効果を考慮してネットワークを適切に表現して管理することができ、最適パスを設定することができるパス設定方法を提供することにある。
【課題を解決するための手段】
【００１４】
上記課題を解決するため、本発明は、データ圧縮・伸長機能を有するネットワーク機器が配置されたリンクを含むネットワークにおけるデータ圧縮の効果を考慮したパス設定方法であって、データ圧縮・伸長機能を有するネットワーク機器を含むノードが、自ノードに接続されたリンクの伝送遅延および自ノードでのデータ圧縮処理による処理遅延の和を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、ルータを含むノードが、自ノードに接続されたリンクの伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、前記ネットワーク機器を含むノードおよびルータを含むノードが、各リンクのメトリックを共有して管理し、該メトリックを元に最適パスを設定することを基本的特徴としている。
【発明の効果】
【００１５】
本発明では、各ノード間のリンクについてのメトリックを遅延として表現するので、ネットワークにWAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器が含まれて入れても、該ネットワーク機器でのデータ圧縮の効果を含めて、ネットワークのメトリックを適切に表現して管理することができ、該メトリックを元に最適なパスを設定することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明による、ネットワーク内に配置されたWAN高速化装置でのデータ圧縮を考慮したパス設定方法を概念的に示す説明図である。
【図２】各ノードにおけるメトリック算出動作の一例を示すフローチャートである。
【図３】各ノードにおけるメトリック算出動作の他の例を示すフローチャートである。
【図４】WAN高速化装置が部分的に配置されたネットワークの例を示すブロック図である。
【発明を実施するための最良の形態】
【００１７】
アプリケーションやサービスにとって、WAN高速化装置でのデータ圧縮による効果は、転送遅延に大きく変動を与える側面が意識されるため、本発明では WAN高速化装置でのデータ圧縮処理による遅延(処理遅延)の変動量をメトリックとして把握することにより上記課題を解決する。
【００１８】
図１は、本発明による、ネットワーク内に配置されたWAN高速化装置でのデータ圧縮を考慮したパス設定方法を概念的に示す説明図である。図１において、図４と同一あるいは同等部分には同じ符号を付している。
【００１９】
図１は、図４と同様のネットワーク10を示す。ネットワーク1Oは、ルータ11〜13、WAN高速化装置14，15をリンク21〜25で接続して構成されている。WAN高速化装置14、15は、リンク21、23に接続されている。ユーザ31、33は、データ圧縮を利用するが、ユーザ32、34は、データ圧縮を利用しない。
【００２０】
ルータ11〜13およびWAN高速化装置14，15はそれぞれ、ノードを構成するので、以下では、それらをノード11〜15と称する。ノード11〜13は、ルータを含むノードであり、ノード14,15は、WAN高速化装置を含むノードである。
【００２１】
ノード11は、自ノードに接続されているリンク21、22、24の伝送遅延を計測し、該伝送遅延を該リンク21、22、24のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード12〜15から広告されるリンクのメトリックを格納する。
【００２２】
ノード12は、自ノードに接続されているリンク22、23、25の伝送遅延を計測し、該伝送遅延を該リンク22、23、25のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11、13〜15から広告されるリンクのメトリックを格納する。ここで、ノード13により算出されたリンク22についてのメトリックは、ノード11から広告されたものと重複するが、両者は同一値であるのでどちらを格納しても問題が生じることはない。
【００２３】
同様に、ノード13も、リンク24、25のメトリックを格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11、12、14、15から広告されるリンクのメトリックを格納する。ここでも、ノード13により算出されたリンク24、25についてのメトリックは、ノード11、12から広告されたものと重複するが、問題が生じることはない。
【００２４】
一方、ノード14は、自ノードに接続されているリンク21の伝送遅延を計測すると共に自ノードのWAN高速化装置でのデータ圧縮処理による遅延(処理遅延)、および該処理遅延とリンク21の伝送遅延の和を算出し、この和を算出してリンク21のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11〜13、15から広告されるリンクのメトリックを格納する。ここでは、ノード14により算出されたリンク21のメトリックは、ノード11から広告されたものと異なる。すなわち、ノード14により算出されるメトリックにはWAN高速化装置でのデータ圧縮処理による処理遅延が加味されているのに対し、ノード11により算出されるメトリックには該処理遅延が加味されていないので、両者に齟齬が生じる。この齟齬に対しては、同一リンクについて異なるメトリックが広告された場合、小さい値の方のメトリックを採用すればよい。
【００２５】
また、ノード15は、自ノードに接続されているリンク23の伝送遅延を計測すると共に自ノードのWAN高速化装置でのデータ圧縮処理による遅延(処理遅延)、および該処理遅延とリンク23の伝送遅延の和を算出してリンク23のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11〜14から広告されるリンクのメトリックを格納する。ここでも、ノード15により算出されたリンク23のメトリックとノード12から広告されたリンク23のメトリックとに齟齬が生じるが、上記と同様に対処すればよい。
【００２６】
なお、各リンクの伝送遅延、WAN高速化装置でのデータ圧縮処理による処理遅延およびメトリックの算出手法については、後で具体的に説明する。
【００２７】
図１は、ノード11がリンク21、22、24のメトリック「0.03」、「0.31」、「0.25」を算出して広告し、ノード12がリンク22、23、25のメトリック「0.31」、「0.06」、「0.11」を算出して広告し、ノード13がリンク24、25のメトリック「0.25」、「0.11」を算出して広告し、ノード14がリンク21のメトリック「0.02」を算出して広告し、ノード15がリンク23のメトリック「0.05」を算出して広告した場合を示している。
【００２８】
ここで、リンク21のメトリックとしては、ノード31から「0.02」が広告される一方、ノード11からは「0.03」が広告されが、小さい方の「0.02」がリンク21のメトリックとされる。同様に、リンク21のメトリックは、「0.05」とされる。
【００２９】
以上のようにして、ノード11〜15により算出された各リンク21〜25のメトリックがOSPF等のプロトコルでネットワーク10全体に広告される結果、ノード11〜15は、ネットワーク10の各リンク21〜25のメトリックを共有することができる。図１では、ここでノード15が格納するリンク21〜25のメトリックを示しているが、他のノード11〜14も同じメトリックを格納する。
【００３０】
各ノードが11〜15格納するメトリックに基づき、例えばDijkstra法により最短経路(遅延が最小の経路、すなわちメトリックの総和が最小となる経路(最もコストの低い経路))のパスを計算することができる。図1の例では、ノード14(ユーザ31)からノード15(ユーザ33)に至る最短経路は、メトリックの総和が0.43となるリンク21−リンク24−リンク25-リンク23を経由する経路であり、この経路に最適パスを設定することができる。
【００３１】
次に、各リンクについての遅延およびメトリックの算出手法について説明する。以下では、WAN高速化装置の出力側リンクの帯域幅をB [b/s]、データのパケットサイズをS [b]、データ圧縮に要する時間をC [s]、データ圧縮/伸長率をRとする。
【００３２】
非特許文献４によると、圧縮可能なパケットの割合の最大値PR(例えば、PR=0.9なら、100個中最大90個のパケットを圧縮可能)は、出力キューが混雑している場合において、x個のパケットに対して1個が圧縮されるとすると、「(x-1)*S/B + R*S/B = C」を満たす。これから「x = B*C/S + (1-R)」が導出される。圧縮可能なパケット数の割合PRは、xの逆数であることから、「PR = 1 / (B*C/S + (1-R))」と表現できる。WAN高速化装置は通常、PRの割合でパケット圧縮を行おうとする。
【００３３】
以上のことを利用してWAN高速化装置でのデータ圧縮処理による処理遅延を見積もることができる。すなわち、WAN高速化装置でデータ圧縮を行わないときのパケット転送までに要する時間をWとすると、WのうちPRの割合に対してデータ圧縮が適用されることから、１つのWAN高速化装置でのデータ圧縮処理による処理遅延は、「R * PR * W + (1 - PR) * W」と見積もることができる。上記の式から明らかなように、WAN高速化装置でのデータ圧縮/伸長率Rが大きくなるに従って、そこでの処理遅延も大きくなるという関係にある。
【００３４】
上記の式を使ってWAN高速化装置でのデータ圧縮の度合いに応じた処理遅延でメトリックを表現することにより、WAN高速化装置でのデータ圧縮の効果を含めてネットワークを管理することが可能になる。
【００３５】
従来OSPFではリンクの帯域量の逆数をメトリックとして扱ってきたが、その代わりに各リンクについての遅延をそのままの値でメトリックとして扱うことにより、OSPFと同様のアルゴリズムで、エンドツーエンドで遅延の少ない経路を計算することができる。つまり、WAN高速化装置でのデータ圧縮処理による処理遅延、リンクの伝送遅延でメトリックを表現し、それを、例えば、RFC3630のSub TLV(time length value)として新たに追加することでネットワークを適切に管理することが可能となる。
【００３６】
図２は、各ノードにおけるメトリック算出動作の例を示すフローチャートである。ここでは、各ノードが自ノードに接続されたリンクについての遅延を算出し、該遅延を当該リンクについてのメトリックとする基本的アルゴリズムを示している。ここで算出された遅延は、OSPF等のプロトコルで各リンクについてのメトリックとして扱うことができる。なお、メトリックを算出するための構成は、ハードウエアでもソフトウエアでも実現できる。
【００３７】
まず、Ping計測を開始する(S21)。Ping計測により当該リンクの伝送遅延(DＬ)が取得される(S22)。リンクの伝送遅延(DＬ)は、定期的な計測により得られる計測値の平均値とするのが好ましい。リンクでの伝送遅延(DＬ)は、WAN高速化装置でのデータ圧縮処理による処理遅延を含まない。
【００３８】
次に、当該リンクがWAN高速化装置を含むノードに接続されたリンクであり、かつメトリックを算出するノードがWAN高速化装置を含むノードであるか否か(図２では、「データ圧縮するリンク？」と記している。)を判定する(S23)。図１の例において、S23がYesとなるのは、ノード14、15でのリンク21、23のメトリック算出の場合であり、ノード11〜13でのメトリック算出の場合にはS23はNoとなる。
【００３９】
S23がYes の場合、当該リンクがWAN高速化装置を含むノードに接続されたリンクであり、かつWAN高速化装置を含むノードでのメトリック算出であるので、まず、WAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)を算出する(S24)。WAN高速化装置のデータ圧縮での処理遅延(DＷ)は、WAN高速化装置で設定されている圧縮/伸張率(R)を用い、上記の式「R * PR * W + (1 - PR) * W」で算出できる。なお、WAN高速化装置の出力リンクの帯域幅B [b/s]、データのパケットサイズS [b]、データ圧縮に要する時間C [s] 、データ圧縮の処理を行わないときのパケット転送までに要する時間Wは、既知であり、これらの値から上記の式のPRやWが得られる。次に、当該リンクについての遅延として、リンクの伝送遅延(DＬ)とWAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)の和を算出し、該和を該リンクのメトリックとして格納する(S25)。
【００４０】
一方、S23がNoの場合、ルータを含むノードでのメトリック算出であるので、リンクの伝送遅延(DＬ)を算出し該リンクのメトリックとして格納する(S26)。なお、以上のフローにより同一リンクについて異なるメトリックが算出されて広告された場合には、上述したように、小さい方のメトリックを採用するようにすればよい。
【００４１】
以上のように、WAN高速化装置でのデータ圧縮の効果としての遅延をOSPFなどのプロトコルによりメトリックとして自動化して扱うことにより、WAN高速化装置を含むネットワークを最適に管理し、最適パスを設定することが可能になる。
【００４２】
図３は、各ノードにおけるメトリック算出動作の他の例を示すフローチャートである。図２ではメトリック算出の際にルータでの転送遅延を加味していないが、図３では、ルータでの転送遅延(DＲ)を加味してメトリックを算出するようにしている。
【００４３】
図３におけるS31〜S35は、図２のS21〜S25と同じであるので、説明を省略する。図１の例では、WAN高速化装置を含むノード14、15がリンク21、23のメトリックを算出する。
【００４４】
S33 がNoの場合、ルータを含むノードでのメトリック算出であるので、リンクの伝送遅延(DＬ) とルータでの転送遅延(DＲ)の和を当該リンクについての遅延として算出し、該和を算出して該リンクのメトリックとして格納する(S36)。ここでは、ルータでのパケット入出力においては入力側と出力側の２つのリンクがあることから、入力側と出力側の２つのリンクに転送遅延(DＲ)の1/2ずつを振り分けるが、リンク両側のルータでの転送遅延(DＲ)の1/2ずつを加算し、結果として、リンクの伝送遅延(DＬ) とルータでの転送遅延(DＲ)の和を当該リンクについての遅延としている。なお、ルータでの転送遅延(DＲ)としては、例えば、ネットワークを構成する複数のルータでの転送遅延の平均など、予め設定した値を用いる。
【００４５】
なお、同一リンクについて異なるメトリックが広告された場合に小さい値の方のメトリックを採用する結果、WAN高速化装置のデータ圧縮での処理遅延(DＷ)が加味されるリンクについてはルータでの転送遅延(DＲ)が加味されないことになるが、ルータでの転送遅延(DＲ)は、WAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)に比べて十分に小さいので、実際上では、これで問題が生じることはない。
【００４６】
以上実施形態について説明したが、本発明は、上記実施形態に限定されない。例えば、図３では、WAN高速化装置でのデータ圧縮処理による処理遅延が加味されるリンクについてはルータでの転送遅延を加味していないが、WAN高速化装置でのデータ圧縮処理による処理遅延が加味されるリンクであっても、ルータでの転送遅延(DＲ)の1/2を加味することもできる。また、ルータから隣接するルータあるいは隣接するWAN高速化装置へ自ルータでの転送遅延を通知する機構を設ければ、通知された転送遅延を使って各リンクについての遅延およびメトリックを算出することも可能になる。
【符号の説明】
【００４７】
10・・・ネットワーク、11〜13・・・ルータを含むノード、14,15・・・WAN高速化装置を含むノード、21〜25・・・リンク、31〜34・・・ユーザ
【技術分野】
【０００１】
本発明は、ネットワークにおけるデータ圧縮の効果を考慮したパス設定方法に関し、特に、WAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器がネットワークに含まれていても、ネットワーク機器でのデータ圧縮の効果を考慮してネットワークを管理することができ、最適パスを設定することができるパス設定方法に関する。
【背景技術】
【０００２】
従来のネットワークでは、ネットワークを構成する各リンクの帯域情報(空き帯域量)を元に最適パスを設定する。このために、ネットワーク内の各ノード(ルータ)は、自ノードに接続されている各リンクの帯域情報を求めて格納すると共に該帯域情報をネットワークに広告し、また、他ノードから広告された帯域情報を格納する。ネットワーク内の各ノードは、ネットワークの帯域情報を共有し、該帯域情報を元に最適パスを設定することができる。非特許文献１，２には、このようなネットワーク管理技術の標準化について記載されている。
【０００３】
近年、従来のルータに加えてWAN(wide area network)高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器(以下では、WAN高速化装置と称する。)がネットワーク内に部分的に配置されるケースがでてきている。WAN高速化装置については、非特許文献３に記載されている。
【０００４】
図４は、WAN高速化装置が部分的に配置されたネットワークを模式的に示すブロック図である。ここでは、ルータ11〜13、WAN高速化装置14，15をリンク21〜25で接続して構成されたネットワーク10を示している。WAN高速化装置14、15は、リンク21、23に接続されている。ユーザ31、33は、データ圧縮を利用するが、ユーザ32、34は、データ圧縮を利用しない。
【０００５】
ネットワーク内にWAN高速化装置が含まれている場合、WAN高速化装置を通して転送されるデータは、そこで圧縮/伸張される。WAN高速化装置は、ネットワークにおける適宜のユーザ側端に配置され、各WAN高速化装置が提供するデータ圧縮率も様々である。このことは、従来のようにリンクの帯域情報でネットワークを適切に表現することを妨げ、したがって、ネットワークを適切に管理することを妨げている。その理由は、後述する。
【０００６】
このように、従来の技術では、WAN高速化装置でのデータ圧縮の効果をデータ伝送上でのネットワークにおける距離、すなわち、「メトリック」として適切に表現することができず、結果として、WAN高速化装置でのデータ圧縮の効果を無視してネットワークを管理せざるを得ない。なお、「メトリック」は、「データ伝送上でのネットワークにおける距離」を表す専門用語であり、メトリックの値が小さくなる程、ネットワークにおけるデータ伝送上の距離が短くなって通信コストが低いことを示す。すなわち、「メトリック」の値は、通信コストを表す。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】RFC3630(Traffic Engineering (TE) Extensions to OSPF Version 2)
【非特許文献２】RFC53058(IS-IS Extensions for Traffic Engineering)
【非特許文献３】WAN高速化(http://www.cisco.com/web/JP/news/cisco_news _letter/ tech/waas2/index.html)
【非特許文献４】M. Shimamura, H. Koga, T. Ikenaga, and M. Tsuru, "Compressing packets adaptively inside networks," IEICE Transactions on Communications, vol. E93-B, no. 3, pp. 501-515, March 2010.
【発明の概要】
【発明が解決しようとする課題】
【０００８】
WAN高速化装置でのデータ圧縮は、リンクの帯域量を実効的に増加させる効果をもたらす。したがって、従来の技術と同様に、リンクの帯域情報をメトリックとして表現してネットワークを管理することが考えられる。具体的には、従来では、RFC3630などOSPF(open shortest path fast)プロトコルが利用されているので、WAN高速化装置にOSPFを適用する方法が考えられる。
【０００９】
しかし、リンクの帯域情報によりネットワークを管理する方法では、例えば、図４のリンク21やリンク23のみ見かけの帯域量を大きくして広告する、というだけでは意味をなさない。すなわち、WAN高速化は、データ圧縮側とデータ伸長側が対となって始めて機能するというエンドツーエンドで機能するという特徴を有し、このため、データ圧縮側とデータ伸長側のWAN高速化装置によって処理されるデータが経由する経路を構成する全てのリンクの帯域量を、WAN高速化装置でのデータ圧縮を考慮した値にする必要がある。
【００１０】
例えば、図４では、リンク22、あるいはリンク24、25についてルータ11 〜13が広告するリンクの帯域量をWAN高速化装置14(あるいはWAN高速化装置15)でのデータ圧縮に応じて変更する必要がでてくる。
【００１１】
実際のネットワークでは、対となるWAN高速化装置の間にはルータが存在することが多く、ルータは、WAN高速化装置とは独立に動作していて、WAN高速化装置でのデータ圧縮に呼応してデータ圧縮する訳ではない。したがって、WAN高速化装置でのデータ圧縮に応じて、それに接続されているリンクのみの帯域量の変動を広告しても、それ以外のリンクの帯域量は不変とされるので、ネットワークが適切に表現されず、適切に管理されないことになる。
【００１２】
また、WAN高速化装置が何対も配置されるケースや、WAN高速化装置でのデータ圧縮が施されないユーザ(図４のユーザ32、34)のトラヒックもあることを考えると、仮にWAN高速化装置にOSPFを実装したとしても問題の解決は困難である。つまり、WAN高速化装置でのデータ圧縮の効果をリンクの帯域情報で表現してネットワークを管理しようとすることには、多くの困難がある。
【００１３】
本発明の目的は、上記課題を解決し、WAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器がネットワークに含まれていても、ネットワーク機器でのデータ圧縮の効果を考慮してネットワークを適切に表現して管理することができ、最適パスを設定することができるパス設定方法を提供することにある。
【課題を解決するための手段】
【００１４】
上記課題を解決するため、本発明は、データ圧縮・伸長機能を有するネットワーク機器が配置されたリンクを含むネットワークにおけるデータ圧縮の効果を考慮したパス設定方法であって、データ圧縮・伸長機能を有するネットワーク機器を含むノードが、自ノードに接続されたリンクの伝送遅延および自ノードでのデータ圧縮処理による処理遅延の和を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、ルータを含むノードが、自ノードに接続されたリンクの伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、前記ネットワーク機器を含むノードおよびルータを含むノードが、各リンクのメトリックを共有して管理し、該メトリックを元に最適パスを設定することを基本的特徴としている。
【発明の効果】
【００１５】
本発明では、各ノード間のリンクについてのメトリックを遅延として表現するので、ネットワークにWAN高速化装置などのデータ圧縮・伸長機能を有するネットワーク機器が含まれて入れても、該ネットワーク機器でのデータ圧縮の効果を含めて、ネットワークのメトリックを適切に表現して管理することができ、該メトリックを元に最適なパスを設定することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明による、ネットワーク内に配置されたWAN高速化装置でのデータ圧縮を考慮したパス設定方法を概念的に示す説明図である。
【図２】各ノードにおけるメトリック算出動作の一例を示すフローチャートである。
【図３】各ノードにおけるメトリック算出動作の他の例を示すフローチャートである。
【図４】WAN高速化装置が部分的に配置されたネットワークの例を示すブロック図である。
【発明を実施するための最良の形態】
【００１７】
アプリケーションやサービスにとって、WAN高速化装置でのデータ圧縮による効果は、転送遅延に大きく変動を与える側面が意識されるため、本発明では WAN高速化装置でのデータ圧縮処理による遅延(処理遅延)の変動量をメトリックとして把握することにより上記課題を解決する。
【００１８】
図１は、本発明による、ネットワーク内に配置されたWAN高速化装置でのデータ圧縮を考慮したパス設定方法を概念的に示す説明図である。図１において、図４と同一あるいは同等部分には同じ符号を付している。
【００１９】
図１は、図４と同様のネットワーク10を示す。ネットワーク1Oは、ルータ11〜13、WAN高速化装置14，15をリンク21〜25で接続して構成されている。WAN高速化装置14、15は、リンク21、23に接続されている。ユーザ31、33は、データ圧縮を利用するが、ユーザ32、34は、データ圧縮を利用しない。
【００２０】
ルータ11〜13およびWAN高速化装置14，15はそれぞれ、ノードを構成するので、以下では、それらをノード11〜15と称する。ノード11〜13は、ルータを含むノードであり、ノード14,15は、WAN高速化装置を含むノードである。
【００２１】
ノード11は、自ノードに接続されているリンク21、22、24の伝送遅延を計測し、該伝送遅延を該リンク21、22、24のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード12〜15から広告されるリンクのメトリックを格納する。
【００２２】
ノード12は、自ノードに接続されているリンク22、23、25の伝送遅延を計測し、該伝送遅延を該リンク22、23、25のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11、13〜15から広告されるリンクのメトリックを格納する。ここで、ノード13により算出されたリンク22についてのメトリックは、ノード11から広告されたものと重複するが、両者は同一値であるのでどちらを格納しても問題が生じることはない。
【００２３】
同様に、ノード13も、リンク24、25のメトリックを格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11、12、14、15から広告されるリンクのメトリックを格納する。ここでも、ノード13により算出されたリンク24、25についてのメトリックは、ノード11、12から広告されたものと重複するが、問題が生じることはない。
【００２４】
一方、ノード14は、自ノードに接続されているリンク21の伝送遅延を計測すると共に自ノードのWAN高速化装置でのデータ圧縮処理による遅延(処理遅延)、および該処理遅延とリンク21の伝送遅延の和を算出し、この和を算出してリンク21のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11〜13、15から広告されるリンクのメトリックを格納する。ここでは、ノード14により算出されたリンク21のメトリックは、ノード11から広告されたものと異なる。すなわち、ノード14により算出されるメトリックにはWAN高速化装置でのデータ圧縮処理による処理遅延が加味されているのに対し、ノード11により算出されるメトリックには該処理遅延が加味されていないので、両者に齟齬が生じる。この齟齬に対しては、同一リンクについて異なるメトリックが広告された場合、小さい値の方のメトリックを採用すればよい。
【００２５】
また、ノード15は、自ノードに接続されているリンク23の伝送遅延を計測すると共に自ノードのWAN高速化装置でのデータ圧縮処理による遅延(処理遅延)、および該処理遅延とリンク23の伝送遅延の和を算出してリンク23のメトリックとして格納すると共に該メトリックをネットワーク10に広告し、また、他ノード11〜14から広告されるリンクのメトリックを格納する。ここでも、ノード15により算出されたリンク23のメトリックとノード12から広告されたリンク23のメトリックとに齟齬が生じるが、上記と同様に対処すればよい。
【００２６】
なお、各リンクの伝送遅延、WAN高速化装置でのデータ圧縮処理による処理遅延およびメトリックの算出手法については、後で具体的に説明する。
【００２７】
図１は、ノード11がリンク21、22、24のメトリック「0.03」、「0.31」、「0.25」を算出して広告し、ノード12がリンク22、23、25のメトリック「0.31」、「0.06」、「0.11」を算出して広告し、ノード13がリンク24、25のメトリック「0.25」、「0.11」を算出して広告し、ノード14がリンク21のメトリック「0.02」を算出して広告し、ノード15がリンク23のメトリック「0.05」を算出して広告した場合を示している。
【００２８】
ここで、リンク21のメトリックとしては、ノード31から「0.02」が広告される一方、ノード11からは「0.03」が広告されが、小さい方の「0.02」がリンク21のメトリックとされる。同様に、リンク21のメトリックは、「0.05」とされる。
【００２９】
以上のようにして、ノード11〜15により算出された各リンク21〜25のメトリックがOSPF等のプロトコルでネットワーク10全体に広告される結果、ノード11〜15は、ネットワーク10の各リンク21〜25のメトリックを共有することができる。図１では、ここでノード15が格納するリンク21〜25のメトリックを示しているが、他のノード11〜14も同じメトリックを格納する。
【００３０】
各ノードが11〜15格納するメトリックに基づき、例えばDijkstra法により最短経路(遅延が最小の経路、すなわちメトリックの総和が最小となる経路(最もコストの低い経路))のパスを計算することができる。図1の例では、ノード14(ユーザ31)からノード15(ユーザ33)に至る最短経路は、メトリックの総和が0.43となるリンク21−リンク24−リンク25-リンク23を経由する経路であり、この経路に最適パスを設定することができる。
【００３１】
次に、各リンクについての遅延およびメトリックの算出手法について説明する。以下では、WAN高速化装置の出力側リンクの帯域幅をB [b/s]、データのパケットサイズをS [b]、データ圧縮に要する時間をC [s]、データ圧縮/伸長率をRとする。
【００３２】
非特許文献４によると、圧縮可能なパケットの割合の最大値PR(例えば、PR=0.9なら、100個中最大90個のパケットを圧縮可能)は、出力キューが混雑している場合において、x個のパケットに対して1個が圧縮されるとすると、「(x-1)*S/B + R*S/B = C」を満たす。これから「x = B*C/S + (1-R)」が導出される。圧縮可能なパケット数の割合PRは、xの逆数であることから、「PR = 1 / (B*C/S + (1-R))」と表現できる。WAN高速化装置は通常、PRの割合でパケット圧縮を行おうとする。
【００３３】
以上のことを利用してWAN高速化装置でのデータ圧縮処理による処理遅延を見積もることができる。すなわち、WAN高速化装置でデータ圧縮を行わないときのパケット転送までに要する時間をWとすると、WのうちPRの割合に対してデータ圧縮が適用されることから、１つのWAN高速化装置でのデータ圧縮処理による処理遅延は、「R * PR * W + (1 - PR) * W」と見積もることができる。上記の式から明らかなように、WAN高速化装置でのデータ圧縮/伸長率Rが大きくなるに従って、そこでの処理遅延も大きくなるという関係にある。
【００３４】
上記の式を使ってWAN高速化装置でのデータ圧縮の度合いに応じた処理遅延でメトリックを表現することにより、WAN高速化装置でのデータ圧縮の効果を含めてネットワークを管理することが可能になる。
【００３５】
従来OSPFではリンクの帯域量の逆数をメトリックとして扱ってきたが、その代わりに各リンクについての遅延をそのままの値でメトリックとして扱うことにより、OSPFと同様のアルゴリズムで、エンドツーエンドで遅延の少ない経路を計算することができる。つまり、WAN高速化装置でのデータ圧縮処理による処理遅延、リンクの伝送遅延でメトリックを表現し、それを、例えば、RFC3630のSub TLV(time length value)として新たに追加することでネットワークを適切に管理することが可能となる。
【００３６】
図２は、各ノードにおけるメトリック算出動作の例を示すフローチャートである。ここでは、各ノードが自ノードに接続されたリンクについての遅延を算出し、該遅延を当該リンクについてのメトリックとする基本的アルゴリズムを示している。ここで算出された遅延は、OSPF等のプロトコルで各リンクについてのメトリックとして扱うことができる。なお、メトリックを算出するための構成は、ハードウエアでもソフトウエアでも実現できる。
【００３７】
まず、Ping計測を開始する(S21)。Ping計測により当該リンクの伝送遅延(DＬ)が取得される(S22)。リンクの伝送遅延(DＬ)は、定期的な計測により得られる計測値の平均値とするのが好ましい。リンクでの伝送遅延(DＬ)は、WAN高速化装置でのデータ圧縮処理による処理遅延を含まない。
【００３８】
次に、当該リンクがWAN高速化装置を含むノードに接続されたリンクであり、かつメトリックを算出するノードがWAN高速化装置を含むノードであるか否か(図２では、「データ圧縮するリンク？」と記している。)を判定する(S23)。図１の例において、S23がYesとなるのは、ノード14、15でのリンク21、23のメトリック算出の場合であり、ノード11〜13でのメトリック算出の場合にはS23はNoとなる。
【００３９】
S23がYes の場合、当該リンクがWAN高速化装置を含むノードに接続されたリンクであり、かつWAN高速化装置を含むノードでのメトリック算出であるので、まず、WAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)を算出する(S24)。WAN高速化装置のデータ圧縮での処理遅延(DＷ)は、WAN高速化装置で設定されている圧縮/伸張率(R)を用い、上記の式「R * PR * W + (1 - PR) * W」で算出できる。なお、WAN高速化装置の出力リンクの帯域幅B [b/s]、データのパケットサイズS [b]、データ圧縮に要する時間C [s] 、データ圧縮の処理を行わないときのパケット転送までに要する時間Wは、既知であり、これらの値から上記の式のPRやWが得られる。次に、当該リンクについての遅延として、リンクの伝送遅延(DＬ)とWAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)の和を算出し、該和を該リンクのメトリックとして格納する(S25)。
【００４０】
一方、S23がNoの場合、ルータを含むノードでのメトリック算出であるので、リンクの伝送遅延(DＬ)を算出し該リンクのメトリックとして格納する(S26)。なお、以上のフローにより同一リンクについて異なるメトリックが算出されて広告された場合には、上述したように、小さい方のメトリックを採用するようにすればよい。
【００４１】
以上のように、WAN高速化装置でのデータ圧縮の効果としての遅延をOSPFなどのプロトコルによりメトリックとして自動化して扱うことにより、WAN高速化装置を含むネットワークを最適に管理し、最適パスを設定することが可能になる。
【００４２】
図３は、各ノードにおけるメトリック算出動作の他の例を示すフローチャートである。図２ではメトリック算出の際にルータでの転送遅延を加味していないが、図３では、ルータでの転送遅延(DＲ)を加味してメトリックを算出するようにしている。
【００４３】
図３におけるS31〜S35は、図２のS21〜S25と同じであるので、説明を省略する。図１の例では、WAN高速化装置を含むノード14、15がリンク21、23のメトリックを算出する。
【００４４】
S33 がNoの場合、ルータを含むノードでのメトリック算出であるので、リンクの伝送遅延(DＬ) とルータでの転送遅延(DＲ)の和を当該リンクについての遅延として算出し、該和を算出して該リンクのメトリックとして格納する(S36)。ここでは、ルータでのパケット入出力においては入力側と出力側の２つのリンクがあることから、入力側と出力側の２つのリンクに転送遅延(DＲ)の1/2ずつを振り分けるが、リンク両側のルータでの転送遅延(DＲ)の1/2ずつを加算し、結果として、リンクの伝送遅延(DＬ) とルータでの転送遅延(DＲ)の和を当該リンクについての遅延としている。なお、ルータでの転送遅延(DＲ)としては、例えば、ネットワークを構成する複数のルータでの転送遅延の平均など、予め設定した値を用いる。
【００４５】
なお、同一リンクについて異なるメトリックが広告された場合に小さい値の方のメトリックを採用する結果、WAN高速化装置のデータ圧縮での処理遅延(DＷ)が加味されるリンクについてはルータでの転送遅延(DＲ)が加味されないことになるが、ルータでの転送遅延(DＲ)は、WAN高速化装置でのデータ圧縮処理による処理遅延(DＷ)に比べて十分に小さいので、実際上では、これで問題が生じることはない。
【００４６】
以上実施形態について説明したが、本発明は、上記実施形態に限定されない。例えば、図３では、WAN高速化装置でのデータ圧縮処理による処理遅延が加味されるリンクについてはルータでの転送遅延を加味していないが、WAN高速化装置でのデータ圧縮処理による処理遅延が加味されるリンクであっても、ルータでの転送遅延(DＲ)の1/2を加味することもできる。また、ルータから隣接するルータあるいは隣接するWAN高速化装置へ自ルータでの転送遅延を通知する機構を設ければ、通知された転送遅延を使って各リンクについての遅延およびメトリックを算出することも可能になる。
【符号の説明】
【００４７】
10・・・ネットワーク、11〜13・・・ルータを含むノード、14,15・・・WAN高速化装置を含むノード、21〜25・・・リンク、31〜34・・・ユーザ
【特許請求の範囲】
【請求項１】
データ圧縮・伸長機能を有するネットワーク機器が配置されたリンクを含むネットワークにおけるデータ圧縮の効果を考慮したパス設定方法であって、
データ圧縮・伸長機能を有するネットワーク機器を含むノードが、自ノードに接続されたリンクの伝送遅延および自ノードでのデータ圧縮処理による処理遅延の和を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、
ルータを含むノードが、自ノードに接続されたリンクの伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、
前記ネットワーク機器を含むノードおよびルータを含むノードが、各リンクのメトリックを共有して管理し、該メトリックを元に最適パスを設定することを特徴とする、ネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項２】
前記ネットワーク機器の出力側リンクの帯域幅をＢ[b/s]、データのパケットサイズをＳ[b]、データ圧縮に要する時間をＣ[s]、データ圧縮/伸長率をＲ、前記ネットワーク機器でデータ圧縮を行わないときのパケット転送までに要する時間をＷとしたとき、ＰＲ＝１/ (Ｂ*Ｃ/Ｓ＋(１−Ｒ))で算出される圧縮可能なパケットの割合の最大値ＰＲを用いて、Ｒ*ＰＲ*Ｗ＋(１−ＰＲ)*Ｗで前記ネットワーク機器でのデータ圧縮処理による処理遅延を算出することを特徴とする、請求項１に記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項３】
前記ルータを含むノードが各リンクについての遅延を算出する際、さらにルータでの転送遅延を加味することを特徴とする、請求項１または２に記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項４】
同一のリンクについて異なる値のメトリックが算出された場合、小さい値の方のメトリックを採用することを特徴とする、請求項１ないし４のいずれか１つに記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項１】
データ圧縮・伸長機能を有するネットワーク機器が配置されたリンクを含むネットワークにおけるデータ圧縮の効果を考慮したパス設定方法であって、
データ圧縮・伸長機能を有するネットワーク機器を含むノードが、自ノードに接続されたリンクの伝送遅延および自ノードでのデータ圧縮処理による処理遅延の和を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、
ルータを含むノードが、自ノードに接続されたリンクの伝送遅延を当該リンクについての遅延として算出し、該遅延を当該リンクのメトリックとして算出し、
前記ネットワーク機器を含むノードおよびルータを含むノードが、各リンクのメトリックを共有して管理し、該メトリックを元に最適パスを設定することを特徴とする、ネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項２】
前記ネットワーク機器の出力側リンクの帯域幅をＢ[b/s]、データのパケットサイズをＳ[b]、データ圧縮に要する時間をＣ[s]、データ圧縮/伸長率をＲ、前記ネットワーク機器でデータ圧縮を行わないときのパケット転送までに要する時間をＷとしたとき、ＰＲ＝１/ (Ｂ*Ｃ/Ｓ＋(１−Ｒ))で算出される圧縮可能なパケットの割合の最大値ＰＲを用いて、Ｒ*ＰＲ*Ｗ＋(１−ＰＲ)*Ｗで前記ネットワーク機器でのデータ圧縮処理による処理遅延を算出することを特徴とする、請求項１に記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項３】
前記ルータを含むノードが各リンクについての遅延を算出する際、さらにルータでの転送遅延を加味することを特徴とする、請求項１または２に記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【請求項４】
同一のリンクについて異なる値のメトリックが算出された場合、小さい値の方のメトリックを採用することを特徴とする、請求項１ないし４のいずれか１つに記載のネットワークにおけるデータ圧縮の効果を考慮したパス設定方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１２−２０９６６０（Ｐ２０１２−２０９６６０Ａ）
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願番号】特願２０１１−７２１８２（Ｐ２０１１−７２１８２）
【出願日】平成２３年３月２９日（２０１１．３．２９）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２２年度、独立行政法人情報通信研究機構「高度通信・放送研究開発委託研究／新世代ネットワークサービス基盤構築技術に関する研究開発 課題イ ネットワーク広域制御を利用するアプリケーションのためのフレームワーク技術」、「ダイナミックネットワーク技術の研究開発 課題エ 大規模資源の管理・制御に関する技術」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【出願人】（５０４１７４１３５）国立大学法人九州工業大学 (489)
【Ｆターム（参考）】
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願日】平成２３年３月２９日（２０１１．３．２９）
【国等の委託研究の成果に係る記載事項】（出願人による申告）平成２２年度、独立行政法人情報通信研究機構「高度通信・放送研究開発委託研究／新世代ネットワークサービス基盤構築技術に関する研究開発 課題イ ネットワーク広域制御を利用するアプリケーションのためのフレームワーク技術」、「ダイナミックネットワーク技術の研究開発 課題エ 大規模資源の管理・制御に関する技術」、産業技術力強化法第１９条の適用を受ける特許出願
【出願人】（０００２０８８９１）ＫＤＤＩ株式会社 (2,700)
【出願人】（５０４１７４１３５）国立大学法人九州工業大学 (489)
【Ｆターム（参考）】
[ Back to top ]