JP3923863B2 - リクエストルータ装置 - Google Patents
リクエストルータ装置 Download PDFInfo
- Publication number
- JP3923863B2 JP3923863B2 JP2002199550A JP2002199550A JP3923863B2 JP 3923863 B2 JP3923863 B2 JP 3923863B2 JP 2002199550 A JP2002199550 A JP 2002199550A JP 2002199550 A JP2002199550 A JP 2002199550A JP 3923863 B2 JP3923863 B2 JP 3923863B2
- Authority
- JP
- Japan
- Prior art keywords
- request
- path
- data
- router
- bandwidth
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/825—Involving tunnels, e.g. MPLS
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/02—Topology update or discovery
- H04L45/10—Routing in connection-oriented networks, e.g. X.25 or ATM
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/12—Shortest path evaluation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
- H04L47/724—Admission control; Resource allocation using reservation actions during connection setup at intermediate nodes, e.g. resource reservation protocol [RSVP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/78—Architectures of resource allocation
- H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/80—Actions related to the user profile or the type of traffic
- H04L47/808—User-type aware
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/70—Admission control; Resource allocation
- H04L47/82—Miscellaneous aspects
- H04L47/822—Collecting or measuring resource availability data
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【発明の属する技術分野】
本発明はデータ要求を複数の中継サーバにリダイレクトするリクエストルータ装置、該装置が接続されるリクエストルーティングネットワーク、および該ネットワークにおけるパス設定方法に関する。
【0002】
【従来の技術】
ADSL(非対称デジタル加入者線;Asymmetric DigitalSubscriber Line)などの高速アクセス技術により、アクセスネットワークの高速化が進んでいる。これに伴い、IP(Internet Protocol)ネットワークを用いて、従来のHTML(ハイパーテキスト・マークアップ・言語;Hyper Text Markup Language)テキストを配信するWWW(ワールド・ワイド・ウェッブ;World Wide Webの略)サービスだけでなく、音楽データや動画などの大容量データの配信サービスも提供され始めている。これらの大容量データは有料で提供されるサービス形態が多く、この場合、サービス提供者は、サービス利用者が契約している高速アクセスネットワークの帯域や、サービスに対して支払う料金に見合う通信品質を保証してデータを配信することが必要になる。
【0003】
保証すべき通信品質はデータの配信・利用形態により異なる。例えば、利用者の端末内の記憶装置に全データが蓄積された後に利用されるデータ配信・利用形態の場合(Video on Demandなど)、考慮すべき通信品質は利用者がデータを要求してから全データが蓄積されるまでの時間になる。また、利用者の端末内の記憶装置に全データが蓄積されないうちに受信データが順次利用されるデータ配信・利用形態の場合(Voice over IP、ライブ放送のストリーミング配信など)、考慮すべき通信品質は、データの転送帯域、遅延等に依存する。
【0004】
上述の通信品質を保証したデータ配信を、大規模ネットワークを用いて多数のユーザに対して提供する技術として、リクエストルーティング技術がある。例えばIETF(インターネット技術標準化委員会;Internet Engineering Task Force)発行のInternet Draft、”Known CN Request−Routing Mechanisms”、draft−ietf−cdi−known−request−routing−00.txt(以下、文献1と称する)に数種類のリクエストルーティング技術が記載されている。
【0005】
上記文献1に紹介されている技術の概要を、図2を用いて説明する。図2では、ネットワーク1、ネットワーク2、ネットワーク3が相互に接続されている。ネットワーク1には端末T1が接続されており、ネットワーク2には端末T2が接続されている。ネットワーク3内には、オリジナルデータを格納するオリジナルサーバS3が配置され、ネットワーク1、ネットワーク2内にはそれぞれ中継サーバS1、S2が配置される。S1、S2内には予めS3内のオリジナルデータがコピーされている。オリジナルデータの中継サーバへのコピー方式は、各中継サーバが独立にオリジナルサーバに最新データを要求するプル型方式、オリジナルサーバが最新データを各中継サーバへ配布するプッシュ型方式、などがある。さらに、ネットワーク3内には端末からのデータ要求に対し、利用者が要求する通信品質を保証して配信することが可能な中継サーバを決定し、データ要求を当該サーバに振り向けるリクエストルータRR1が配置される。RR1は各中継サーバに格納しているデータの種類や、中継サーバのMPU負荷、各中継サーバから利用者端末までの配信経路における遅延時間や余剰帯域を監視し、それらの情報を管理している。
【0006】
次にリクエストルーティング処理動作について説明する。T1は最初にデータ要求をRR1に対して送信する。図2では上記データ要求を矢印21で示す。RR1はデータ要求を受信すると、要求されたデータが中継サーバに格納されているかという情報、各中継サーバのMPU負荷、T1までの配信経路の遅延時間や余剰帯域、などを考慮し、T1へのデータ配信に最適な中継サーバを決定する。その後、RR1は最適なサーバがS1であることをT1へ通知する。通知する情報としては、S1のIP(インターネットプロトコル;Internet Protocol)アドレスが挙げられる。図2では上記通知を矢印22で示す。最適なサーバとして、S1を通知されたT1は、S1に対してTCP(転送制御プロトコル;Transmission Control Protocol)などのコネクションを設定する。図2では、上記のコネクション設定を矢印23で示す。T1は、上記設定されたコネクションを用いて、S1からデータを取得する。図2では、このデータ取得を矢印24で示す。
【0007】
上記文献1に紹介されている技術を用いることにより、端末の近辺に分散配置された複数の中継サーバに、各端末からのデータ要求を分散させることができる。また、オリジナルサーバが各端末のデータ要求を全て処理する場合に比べて、配信経路の遅延時間が小さくなり、また、配信経路の混雑によるデータ配信の通信品質の劣化を抑制することができる。また、中継サーバのMPU負荷に応じて、端末のデータ要求を分散することができる。従って、大多数の端末に対し通信品質を保証したデータ配信が可能になる。
【0008】
一方、上述の通信品質を保証したデータ配信を、多数のユーザに対して低価格で実現するためには、上記文献1に開示されている技術に加えて、データ配信に用いるネットワークのリソース利用技術が有効である。上記のネットワークリソースを有効利用する技術として、MPLS(Multi Protocol Label Switching)を用いたトラフィックエンジニアリング技術がある。MPLSに関しては、例えばIETF(インターネット技術標準化委員会;Internet Engineering Task Force)発行のRFC(Request For Comment)3031、”Multiprotocol Label Switching Architecture”(以下、文献2と称する)に記載されている。また、MPLSを用いたトラフィックエンジニアリング技術に関しては、例えばIETF発行のRFC2702、”Requirements for Traffic Engineering Over MPLS”に概要が記載されている。
【0009】
上記の文献2に開示されている技術を用いることにより、明示的にパスを設定し、トラフィックの一部を上記設定したパスに分配することにより、ネットワークの輻輳ポイントの負荷を分散することが可能となる。また、ネットワーク資源を有効に利用できるので、データ配信のコストを下げることが可能である。
【0010】
【発明が解決しようとする課題】
しかしながら、前述した文献1及び2に開示されている技術では、低価格で多数の利用者に対し通信品質を保証したデータ配信サービスを行う場合、以下に示す問題が生じる。
【0011】
上記文献1に開示されている技術では、リクエストルータが各中継サーバのMPU負荷や、各中継サーバから端末までの配信経路の負荷に基づき、端末へのデータ配信に最適な中継サーバを決定するが、ネットワークの状態を動的に制御しないため、サーバ資源とネットワーク資源の両方を有効利用することができない場合がある。
【0012】
例えば、配信経路の遅延は最小で、MPU負荷も小さいが、配信経路上で輻輳が発生しているため利用者の要求品質を保証できないと判断し、より遅延時間が大きくなる別の中継サーバを選択してしまう可能性がある。この場合、MPU負荷が小さいサーバの余剰資源は利用されない。また、上記の輻輳が発生している経路の近辺にネットワークの余剰資源があっても、上記余剰資源は利用されない。
【0013】
また、上記文献2に開示されている明示的パス設定方法は、ネットワーク管理者やパス管理サーバが利用者からのデータ要求とは全く独立にネットワークを監視、管理するだけであり、データ要求に対応して動的にパスを設定して帯域を確保することはできない。
【0014】
本発明の第1の目的は、データ要求に対してネットワークの状態を動的に制御し、多数の利用者に対し高品質なデータ配信を低価格に提供するリクエストルーティングネットワークを提供することである。
【0015】
また、本発明の第2の目的は、上記リクエストルーティングネットワークに接続されているリクエストルータ装置、ルータ装置及び該装置を利用したパス設定方法を提供することにより、上記データ要求に対して中継サーバから端末への配信経路上の帯域を動的に制御し、上記帯域が不足している場合は新たに経路を設定することにより帯域を増やすことである。
【0016】
【課題を解決するための手段】
上記の課題を解決し、データ要求に対してネットワークの状態を動的に制御し、多数の利用者に対し高品質なデータ配信を低価格に提供することを可能にする為に、本発明は少なくとも一つの種類のデータのコピーを保持する複数のサーバと、該データを要求する複数の端末と、前記データ要求を前記複数のサーバに対しリダイレクトするリクエストルータとが複数のルータによって相互に接続され、前記リクエストルータは前記データ要求を受けて、前記サーバに対し前記リダイレクトする前に、前記サーバに近接して接続されたルータの1つに対し、前記データを配信する為の新たなパスの計算及び設定を要求することを特徴とするリクエストルーティングネットワークを提供することにある。
【0017】
【発明の実施の形態】
以下、本発明の実施例を各図を用いて説明する。本実施例の各図における同一符号は同一物または相当物を示す。
【0018】
本発明のリクエストルーティングネットワークの一実施例を、図3を用いて説明する。図3は本発明のリクエストルーティング方式を適用したネットワークの一構成例である。図3に示すネットワークは、複数のネットワーク1、2、3から構成される。ネットワーク1はルータR11、R12、R13から構成される。R11はR11−R13間の回線とインターフェースIF11_13で接続される。R13はR13−R12間の回線とインターフェースIF13_12で接続される。R12はR12−T1間の回線とインターフェースIF12_1で接続される。また、ネットワーク2はルータR21、R22、R23から構成される。ネットワーク3はル−タR31とオリジナルデータサーバS3、およびリクエストルータRR3から構成される。ネットワーク1のルータR12には利用者の端末T1が接続される。また、ネットワーク1のルータR11には中継サーバS1が接続される。ネットワーク2のルータR22には利用者の端末T2が接続される。また、ネットワーク2のルータR23には中継サーバS2が接続される。
【0019】
ルータR11、R12、R13、R21、R22、R23はExtensions to Resource Reservation Protocol for LSP Tunnels(RSVP−TE)、Constraint−based Routing Label Distribution Protocol(CR−LDP)などのMPLSのラベル分配プロトコルを処理する機能を保持する。また、ルータR11、R12、R13、R21、R22、R23は、トラフィックエンジニアリング用に拡張されたOSPF(Open Shortest Pass Fastの略)、あるいはIS−IS(Intermediate System−Intermediate Systemの略)を処理する機能を保持する。トラフィックエンジニアリング用に拡張されたOSPFに関しては、IETF発行のInternet Draft、”Traffic Engineering Extensions to OSPF”、draft−katz−yeung−ospf−traffic−06.txtに記載されている。また、トラフィックエンジニアリング用に拡張されたIS−ISに関しては、IETF発行のInternet Draft、”IS−IS extensions for Traffic Engineering”、draft−ietf−isis−traffic−04.txtに記載されている。
【0020】
サーバS1、S2、S3に最も近いルータR11、R23、R31は、RR1からパス計算・設定要求を受信し、要求された帯域を確保できる新たなパスを計算し、RSVP−TE、CR−LDPなどのラベル分配プロトコルを用いてパス設定の起動をかける機能を保持する。
【0021】
さらに、図3に示されているルータR11、R13間において転送されるラベル“L11_13”付きパケットP及びルータR13、R12間において転送されるラベル“L13_12”付きパケットP等の内容については、後述する図11、図12、図13のテーブルの説明にて、詳述する。
【0022】
図1に本発明によるリクエストルータRR1の一構成例を示す。リクエストルータRR1は、入力インターフェース101、プロトコル解析部102、リクエストルーティング処理部110、パス設定処理部103、中継サーバ監視部104、配信経路監視部105、出力インターフェース106、制御部107から構成される。リクエストルーティング処理部110は、利用者識別・データアクセス認証処理部111、中継サーバ候補選択部112、利用者情報テーブル113、データ管理テーブル114、中継サーバ情報テーブル115、配信経路情報テーブル116から構成される。リクエストルータRR1の構成要素101〜116の実現方法は、専用のハードウェアでもよいし、あるいは、ネットワーク・インターフェースとMPU、メモリ等から構成される汎用のコンピュータ上で動作するソフトウェアプログラムでもよい。
【0023】
次に、図4を用いて、T1からのデータ要求をRR1が適切な中継サーバへ振り向けるリクエストルーティング処理の一例について説明する。なお、以下で説明する例では、T1とRR1間の通信やT1と中継サーバ間のデータ転送のため、OSI(Open System Interconnectionの略)モデルの4層プロトコルとして、TCP(転送制御プロトコル)のようなコネクション型のプロトコルを用いている。しかしながら、4層におけるデータ転送の信頼性が必要でない場合には、UDP(User Datagram Protocolの略)等のプロトコルを用いることも可能である。また、3層プロトコルとしてはIP(Internet Protocol)等のプロトコルが、用いられる。さらに、3層未満のプロトコルとしてはSONET/SDH(Synchronous Optical Network/ SynchronousDigital Hierarchyの略)、Ethernet(登録商標)、ATM (Asynchronous Transfer Modeの略)、MPLS(Multi−Protocol Label Switchingの略)等のプロトコルを用いることができる。
【0024】
T1はまず、RR1との間で通信コネクションを確立する。なお、図4では、コネクション確立に関しては省略している。次に、T1はRR1に対して利用者認証要求600を発行し、端末T1を使用している利用者が、正規の利用者であるのかどうかをRR1に問い合わせる。ここで、T1からRR1に送信される要求メッセージの一構成例を図5に示す。図5では、認証要求600にて用いられる要求メッセージ70は、要求コマンド71、ユーザ識別子72、ユーザパスワード73、データ識別子74の各フィールドから構成されている。要求コマンド71は、要求メッセージ70の発信元装置が送信先装置に依頼する処理の内容を示すフィールドである。要求コマンド71の例としては、ユーザ認証、データ読出し要求、データ書込み要求、などがある。利用者識別子72とユーザパスワード73は、T1を使用している利用者の認証と、利用者が各要求コマンド71を使用する権限を持つのかを確認するために使用される情報である。データ識別子74は、ディレクトリ名/ファイル名、あるいはHTTP(ハイパーテキスト転送プロトコル)におけるURL(Uniform Resource Locatorの略)やURI(Uniform Resource Identifierの略)のような、要求コマンド71に従って、要求送信先で処理されるデータの論理的な位置を示す情報である。
【0025】
T1からのRR1への利用者認証要求600(図4)に対し、RR1は利用者認証処理601を行い、T1に対して、利用者認証応答602を返信する。ここで、図6に利用者認証応答602にて用いられる応答メッセージの一構成例80を示す。応答メッセージ80は応答コマンド81、利用者識別子82、データ識別子83の各フィールドを持つ。応答コマンド80は要求コマンドで要求された処理と処理のステータス、例えば、処理完了あるいは処理不成功等を示す情報を持つ。利用者識別子82は応答を受信する利用者を特定するための情報である。データ識別子83は、処理を行ったデータの論理的な位置を示す情報である。利用者認証応答602によって、T1の利用者が正規の利用者であることを確認した後、T1はRR1に対してデータ要求603を送信する。
【0026】
T1からのデータ要求603を受信したRR1は、次に、中継サーバ候補判定処理604を行う。以下では、中継サーバ候補判定処理604については後に詳細に説明する。中継サーバ候補判定処理604では、様々な中継サーバの候補の決定処理ポリシーを適用することが可能である。本実施例では、以下で説明するような決定処理ポリシーを例にして説明する。本実施例で説明する決定処理ポリシーは、まず、中継サーバから端末までの遅延時間が最小かつ中継サーバのMPU負荷が最小、という条件で複数の中継サーバから候補を絞りこむ。図4では、上記のポリシーにより、中継サーバ候補としてS1が選択された場合を示している。その後、絞りこまれた中継サーバ候補S1から端末T1までの経路(以下、配信経路と呼ぶ)上でデータ配信に必要な帯域を確保できるかどうかを判定する。
【0027】
配信経路上で必要な帯域を確保できない場合、パス計算・設定要求605を用いて、S1とT1間で必要な帯域を確保可能な新たな配信経路を設定できるかどうかを、中継サーバ候補S1に最も近いルータR11に問い合わせる。なお、以下では中継サーバに最も近いルータを始点ルータと呼ぶ。また、端末に最も近いルータを終点ルータと呼ぶ。図3において、S1−T1間の配信経路の始点ルータはR11であり、終点ルータはR12である。RR1は、パス計算・設定要求605を送信する前にR11との間にコネクションを確立してもよいが、図4では省略している。
【0028】
図4のパス計算・設定要求605にて用いられるパス計算・設定要求メッセージの一構成例90を図7に示す。パス計算・設定要求メッセージ90は、コマンド種別91、要求メッセージ識別子92、要求帯域93、終点ルータ識別子94、フロー95の各フィールドから構成される。コマンド種別91は、パス計算・設定要求605や応答を行うRR1と始点ルータR11間のメッセージ種別の識別に用いられる。このフィールドに格納される値により要求メッセージか応答メッセージかを識別できる。要求メッセージ識別子92は、リクエストルータRR1が送信する複数のパス計算・設定要求メッセージ90と、リクエストルータが他のルータから受信する複数の応答メッセージとを対応づけるために用いられる。要求帯域93は、始点ルータR11−終点ルータR12間に設定すべき新たなパス上で確保すべき帯域を示す。終点ルータ識別子94は、新たに計算するパスの終点ルータを示し、本実施例の場合、終点ルータのIPアドレスの値が格納される。
【0029】
次に、フロー95について説明する。フローとはルータにおいて同一の通信品質制御を行うべきパケットの集合である。フローはパケットのIP(Internet Protocol)ヘッダやTCP(転送制御プロトコル)ヘッダの情報を用いて定義する。本実施例の場合、S1からT1へ配信されるデータを構成するパケットは全て同一の通信品質を保証することが要求される。従って、これらのパケットの集合をフローとして定義し、上記のフローに対して同一の通信品質を保証する。上記フローを定義するために、本実施例では、S1からT1へ配信されるデータのフローを、”宛先IPアドレスがT1のIPアドレスに等しい”かつ”送信元IPアドレスがS1のIPアドレスに等しい”と定義し、上記の条件を図7のパス計算・設定要求メッセージ90のフロー95に格納する。このフローの定義はRR1を管理する管理者のポリシーによって自由に設定可能である。
【0030】
パス計算・設定要求605を受信したR11は、パス計算・設定要求メッセージ90内の要求帯域93、終点ルータ識別子94を用いて、R11−R12間で要求帯域93を確保できる新しいパスが設定できるかどうかを計算する(ステップ606)(図4)。本実施例では、上記の計算には、トラフィックエンジニアリング用に拡張されたOSPF、あるいはIS−ISで配布される各ルータのリンクの帯域情報をもとにしたトラフィックエンジニアリング用データベースと、上記TE(トラフィックエンジニアリング)データベースを用いて要求帯域93を確保可能な経路を計算するConstrained Shortest Path Fast(CSPF)アルゴリズムを用いる。各ルータは、トラフィックエンジニアリング用に拡張されたOSPF、あるいはIS−ISなどを用いて、各ルータが収容するリンク情報、例えば、使用可能な帯域の総量、予約可能な帯域の総量、予約可能であるが未予約の帯域、などの情報を通知する。これらの情報を元に各ルータ内にTEデータベースが構築される。このTEデータベースをもとに、各ルータは要求された帯域を確保可能なパスをCSPFアルゴリズムにより計算する。上記のパス計算の結果、要求帯域93を確保可能なパスが存在する場合、R11は上記の経路上のルータのリストを用いて一つ下流のルータR13に対してパス設定要求を行う(ステップ607)(図4)。
【0031】
図4のパス設定要求607、608にて用いられるパス設定要求メッセージ110の一構成例を図9に示す。パス設定要求メッセージ110は、コマンド種別111、要求メッセージ識別子112、パス識別子113、設定帯域114、ルータリスト115の各フィールドから構成される。コマンド種別111は、各ルータ間で通信されるメッセージの種別の識別に用いられる。このフィールドに設定される値により、パス設定要求か応答メッセージかを識別できる。要求メッセージ識別子は、パス設定要求を行う始点ルータが送信する複数のパス設定要求メッセージと、始点ルータが他のルータから受信する複数のパス設定応答メッセージとを対応づけるために用いられる。パス識別子は、新たに設定されるパスを識別するために用いられる。また、設定帯域114は各ルータの帯域保証機能の設定値として用いられ、各ルータはこの設定値に従い、設定パス上で送信されるパケットに対し、帯域を保証しながら転送する。ル−タリスト115は、ルータ数1151と新たに設定するパス上の複数のルータ識別子1152−n(n=ルータ数1511の設定値)から構成される。パス設定要求メッセージを受信したルータは、上記ルータリスト115内のルータ識別子1152−i(i= 1 〜n)を参照して、次にパス設定要求を転送すべきルータを決定し、パス設定要求メッセージを転送することができる。
【0032】
図4において、パス設定要求を受信したR13は、パス設定要求メッセージ内のルータリスト115から、次にパス設定要求メッセージを送信すべきルータをR12と決定し、R12にパス要求メッセージを送信する(ステップ608)。上記パス設定要求を受信したR12は、パス設定要求メッセージ内のルータリスト115から、自身が新しいパス設定の終端点であることを認識する。その後、新しく設定するパスに対する上流ルータR13用のMPLSラベルを決定し、その値をR12内のラベルテーブルに格納する。また、上記MPLSラベルを付与されたパケットに対して保証する帯域値として、パス設定要求メッセージ110内の設定帯域フィールド114に格納されている値を設定する。
【0033】
R12内のラベルテーブルの一構成とその設定例を図11に示す。R12のラベルテーブル130は、入力ラベル131、出力ラベル132、出力インターフェース133、保証帯域134を一組とする複数のエントリから構成される。上記のラベルテーブルへの格納処理により、エントリ13012が新たに登録される。エントリ13012の入力ラベルはR12が決定する値であり、本設定例ではラベル”L13_12”が設定される。また、R12がMPLSネットワーク1の出力エッジルータであるため、出力ラベルは”無し”と設定される。従って、入力パケットはMPLSラベルを除去されIPパケットとしてT1へ転送される。エントリ13012の出力インターフェースには、T1が接続されている”IF12_1”が設定される。エントリ13012の保証帯域には本実施例の場合、”5Mbit/sec”が設定される。
【0034】
ラベルテーブルエントリ13012の設定後、R12はR13に対してパス設定応答を行う(ステップ609)。
【0035】
図4のパス設定応答609、610にて用いられるパス設定応答メッセージの一構成例を図10に示す。パス設定応答メッセージ120は、コマンド種別111、要求メッセージ識別子112、パス識別子113、パス設定結果121、設定ラベル122、設定帯域114から構成される。コマンド種別111、要求メッセージ識別子112、パス識別子113、設定帯域114はパス設定要求メッセージ110内のフィールドと同様である。パス設定結果121は、下流のルータのパス設定が成功か不成功かを示す。パス設定結果121に”不成功”を示す値が格納されている場合、パス設定応答メッセージ120を受信したルータは、ラベルテーブル設定や帯域保証値の設定を実行せず、上流のルータにパス設定応答メッセージを送信する。この際、ルータが送信するパス設定応答メッセージ120内のパス設定結果121には受信したパス設定応答メッセージ120内パス設定結果フィールド内に設定されたものと同じ”不成功”を示す値を格納する。パス設定結果121に”成功”を示す値が格納されている場合、パス設定応答メッセージ120を受信したルータは上流ルータ用のMPLSラベルの決定、ラベルテーブルへの格納、帯域設定を行い、上流のルータにパス設定応答メッセージを送信する。設定ラベル122には、パス設定応答メッセージを受信したルータが上流のルータ用に決定したMPLSラベルを格納する。R12からのパス設定応答メッセージ120を受信したR13は、R12と同様にして、新しく設定するパスに対する上流ルータR11用のMPLSラベルの決定、R13内のラベルテーブルへの格納、帯域設定を行う。
【0036】
R13内のラベルテーブルの一構成とその設定例を図12に示す。R13のラベルテーブルの構成は、R12のラベルテーブル130と同等である。新たに登録されるエントリ13013の入力ラベルはR13が決定する値であり、本設定例ではラベル”L11_13”が設定される。また、エントリ13013の出力ラベルには、R12から受信したパス設定応答メッセージ内の設定ラベルフィールドに格納された値が設定される。本実施例では、R12でR13用に決定したラベルは”L13_12”であり、この値が設定される。エントリ13013の出力インターフェースには、R12が接続されている”IF13_12”が設定される。エントリ13013の保証帯域にはR12に設定された値と同じ”5Mbit/sec”が設定される。
【0037】
ラベルテーブルエントリ13013の設定後、R13はR11に対してパス設定応答を行う(ステップ610)。R13からのパス設定応答メッセージを受信したR11は、R12と同様にして、新しく設定するパスに対する上流ルータR11用のMPLSラベルの決定、R13内のラベルテーブルへの格納、帯域設定を行う。
【0038】
R11内のラベルテーブルの一構成とその設定例を図13に示す。R11はMPLSネットワークの入力エッジルータであるため、R11のラベルテーブル150は、フロー151、出力ラベル132、出力インターフェース133、保証帯域134から構成される。上記のラベルテーブルへの格納処理により、エントリ15011が新たに登録される。エントリ15011のフロー151には、RR1から受信したパス計算・設定要求メッセージ内のフローフィールドに格納されているフローの定義が設定される。本設定例ではフロー定義、”宛先IPアドレスがT1のIPアドレスに等しい”かつ”送信元IPアドレスがS1のIPアドレスに等しい”が設定される。
【0039】
また、エントリ15011の出力ラベルには、R13から受信したパス設定応答メッセージ120内の設定ラベルフィールドに格納された値が設定される。本実施例では、R13でR11用に決定したラベルは”L11_13”であり、この値が設定される。エントリ15011の出力インターフェースには、R13が接続されている”IF11_13”が設定される。エントリ15011の保証帯域にはR13に設定された値と同じ”5Mbit/sec”が設定される。
【0040】
ラベルテーブルエントリ15011の設定後、R11はRR1に対してパス計算・設定応答を行う(ステップ611)。図4のパス計算・設定応答611にて用いられるパス計算・設定応答メッセージ100の一構成例を図8に示す。パス計算・設定応答メッセージ100は、コマンド種別91、要求メッセージ識別子92、パス計算結果101、パス設定結果102、設定帯域103、パス識別子104の各フィールドから構成される。コマンド種別91、要求メッセージ識別子92は、パス計算・設定要求メッセージ90(図7)内のフィールドと同等のフィールドである。パス計算結果101には、R11でのパス計算の結果が格納される。パス計算の結果、要求帯域を確保できるパスを計算できた場合には”成功”を示す値を、パスを計算できなかった場合は”不成功”を示す値を格納する。パス設定結果102には、上記でパス計算に成功した際に、パス設定に成功したかどうかを設定する。パス設定完了の場合は”成功”を示す値を、パス設定ができなかった場合には”不成功”を示す値を格納する。設定帯域はパス設定に成功した際の、実際に設定した帯域を格納する。この設定帯域の値は、本実施例では、パス計算・設定要求メッセージ90内の要求帯域93と同一の値になる。本実施例とは別の方法を用い、上記の設定帯域の値に、パス計算・設定要求メッセージ内の要求帯域とは異なる値が設定されてもよい。
【0041】
この別の方法としては、パス計算・設定要求メッセージ90内に要求帯域93の厳密さを示すフラグを設け、このフラグの値により、要求帯域に余裕を持たせるという方法がある。厳密さを示すフラグが”厳密”を示す際には、要求帯域を確保するように始点ルータは計算を行う。その結果、パスが存在しない場合は”不成功”と通知する。厳密さを示すフラグが”厳密でない”を示す場合には、要求帯域を確保できるパスが存在しない場合、要求帯域の半分の値を条件に再度計算をしてもよい。その結果、要求帯域の半分の値を確保できるパスが存在する場合には、パス計算・設定応答メッセージ100内のパス計算結果101には”成功”を示す値を格納し、設定帯域103には、要求帯域の半分の値を格納する。このようなパス計算・設定応答メッセージ100を受信したRR1は、要求帯域から設定帯域を減算した帯域を新たな要求帯域として、別の始点ルータに対してパス計算・設定要求を行ってもよい。上記の方法を用いると、要求帯域に対して厳密にパス計算を行い、その結果、パス計算不成功という応答を返す場合よりも、効率的なネットワーク資源の有効利用が可能となる。
【0042】
パス識別子はRR1が新しく設定されたパスを配信経路として管理するために用いる。新しく設定されたパスの設定帯域に余裕がある場合、別の端末からのデータ要求を振り向ける中継サーバを決定する際、配信経路として上記のパスも考慮することが可能になる。
【0043】
パス計算・設定応答611を受信したRR1は、新たに設定されたパス情報(設定帯域、パス識別子など)をRR1内の配信経路情報テーブル116に追加する(ステップ612)。その後、RR1は、T1からのデータ要求をS1へリダイレクトする(ステップ613)。
【0044】
RR1からリダイレクトされたデータ要求を受信したS1は、要求メッセージ70(図5)内のデータ識別子74を用いて配信すべきデータを決定し、T1へデータを配信する(ステップ614)。
【0045】
S1はデータを複数のIPパケットに分割して送信する。S1から上記IPパケットを受信したR11は、受信パケットヘッダ情報を検索キーにして、図13で説明したラベルテーブルを検索する。本実施例の場合、パケットヘッダ情報から宛先IPアドレスと送信元IPアドレスを抽出し、ラベルテーブルに設定された各エントリのうち、フロー151に設定された条件が上記抽出した宛先IPアドレスと送信元IPアドレスと一致するエントリを検索する。S1からT1へ送信されたデータパケットに関しては、図13のエントリ15011のフローに設定された条件と一致する。
【0046】
従って、検索結果は、出力ラベル”L11_13”、出力インターフェース”IF11_13”、保証帯域”5Mbit/sec”となる。上記の検索結果に従い、R11は、図3に示すようにIPパケットにラベル”L11_13”を付与し、帯域5Mbit/secを保証して出力インターフェースIF11_13からR13に向けてパケットを転送する。R11から上記パケットを受信したR13は、受信パケットのラベルを検索キーにして、図12で説明したラベルテーブルを検索する。本実施例の場合、ラベルテーブルに設定された各エントリのうち、入力ラベル131に設定された値が、パケットに付与されたラベルの値と一致するエントリを検索する。受信パケットは、R11においてラベル”L11_13”を付与されているため、図12のエントリ13013の入力ラベルフィールドに設定された値と一致する。従って検索結果は、出力ラベル”L13_12”、出力インターフェース”IF13_12”、保証帯域”5Mbit/sec”となる。上記の検索結果に従い、R13は、図3に示すようにIPパケットに付与されているラベル”L11_13”を”L13_12”に置き換え、帯域5Mbit/secを保証して出力インターフェースIF13_12からR12に向けてパケットを転送する。R13から上記パケットを受信したR12は、受信パケットのラベルを検索キーにして、図11で説明したラベルテーブルを検索する。R13と同様に、ラベルテーブルに設定された各エントリのうち、入力ラベル131に設定された値が、パケットに付与されたラベルの値と一致するエントリを検索する。受信パケットは、R13においてラベル”L13_12”を付与されているため、図11のエントリ13012の入力ラベルフィールドに設定された値と一致する。従って検索結果は、出力ラベル”無し”、出力インターフェース”IF12_1”、保証帯域”5Mbit/sec”となる。上記の検索結果に従い、R12は、IPパケットに付与されているラベル”L13_12”を除去し、帯域5Mbit/secを保証して出力インターフェースIF12_1からT1に向けてパケットを転送する。その後、T1はR12から転送されたIPパケットを受信する(ステップ615)。
【0047】
以上、T1のデータ要求に対して、帯域保証可能な新しいパスを設定し、データ要求をS1にリダイレクトさせるリクエストルーティング処理について説明した。ここで、上記IPパケットは図3に示す通り、符号Pで表記されている。このパケットPの内容は常時同一の内容に限定されない。
【0048】
次に、本発明のリクエストルーティングネットワークと、上記文献1に開示されている技術を用いたリクエストルーティングネットワークとで、リクエストの振り向け先およびデータ転送経路の違いについて図15、図16を用いて説明する。図15、図16のネットワーク構成は、図3と同様である。図15、図16において、T1からのデータ要求に対し、転送に必要な帯域を、最短経路であるS1−R11−R12−T1という経路上で確保できない場合の例を示す。この際、R11−R12間の回線に輻輳が発生していると仮定する。また、R11−R13−R12間の経路上では、T1が要求するデータを転送するために必要な帯域を確保できる場合を示す。図15に本発明のリクエストルーティングネットワークを用いた場合のデータ転送経路を示す。また、図16に上記文献1のリクエストルーティングネットワークを用いた場合のデータ転送経路を示す。図15、図16において、実線の矢印181、191がそれぞれのデータ転送経路とデータ転送方向を示す。また、図15、図16において点線の矢印182はS1−R11−R12−T1間にデータ転送に必要な帯域が確保できた場合の転送経路であり、比較のために示している。本発明の実施形態を用いた場合、S1−R11−R12−T1間に帯域が確保できた場合に比較してルータのホップ数は1増加する。
【0049】
これに比べて、上記文献1に開示されている技術を用いた場合、S1−R11−R12−T1間に帯域が確保できた場合に比較してルータのホップ数は2増加する。従って、上記文献1に開示されている技術を用いた場合に比べて本発明の実施形態を用いた場合、T1がサーバからデータを受信する際の遅延を小さくすることが可能となる。また、転送経路がネットワーク1−ネットワーク2間に渡って設定される上記文献1を用いた場合に比べて、本発明を用いた場合、転送経路をT1の近辺のネットワーク内に局所化することができ、他のネットワーク間の転送データ量を抑えることができる。このため、ネットワーク間に予め用意すべき回線帯域を抑えることが可能となり、低価格化につながる。
【0050】
次に、設定したパスの開放動作について図4を用いて説明する。RR1はパス設定後定期的に上記パスの使用状況を監視する(ステップ616)。上記のパスの使用帯域が予め設定してある閾値以下になった場合、RR1はR11に対してパス開放要求を行う(ステップ617)。この際、パス開放要求メッセージには、開放すべきパスのパス識別子が図9のパス設定要求メッセージ110にパス識別子113が格納されるのと同じ要領にて格納されている。パス開放要求を受信したR11は、まず、開放すべきパス識別子を用いてラベルテーブル内の消去すべきエントリを決定し、エントリを消去する。その後、下流のルータR13に対してラベル開放要求を行う(ステップ618)。ラベル開放要求メッセージ内には、開放すべきラベルの値が格納されている。ラベル開放要求を受信したR13は、まず、ラベル開放要求メッセージ内のラベルの値を用いてラベルテーブル内の消去すべきエントリを決定し、エントリを消去する。その後、下流のR12に対してラベル解放要求を行う(ステップ619)。ラベル開放要求を受信したR12は、まず、ラベル開放要求メッセージ内のラベルの値を用いてラベルテーブル内の消去すべきエントリを決定し、エントリを消去する。その後、自身がMPLSネットワークの出力エッジルータであることを考慮し、上流のR13に対してラベル開放応答を行う(ステップ620)。ラベル開放応答メッセージを受信したR13は、上流のR11に対してラベル開放応答を行う(ステップ621)。ラベル開放応答メッセージを受信したR11は、パス上のラベルが全て開放されたことを認識し、RR1に対してパス開放応答を行う(ステップ622)。パス開放応答メッセージ内には開放されたパス識別子が図10のパス設定応答メッセージ120にパス識別子113が格納されるのと同じ要領にて格納されている。パス開放応答メッセージを受信したRR1は、パス開放応答メッセージ内のパス識別子を用いて、RR1内の経路管理テーブルから消去すべきパスを決定し、消去する。
【0051】
以上で説明したパスの開放動作を行うことにより、不必要なパスを開放することができ、各ルータのパスの処理負荷を軽減することができる。また、各ルータのラベルテーブルのエントリ数も節約できる。また、リクエストルータ内の配信経路情報テーブル内のエントリ数も節約できる。
【0052】
次に、R11でのパス計算の結果パスが存在しなかった場合の、次候補の中継サーバに対する帯域要求の処理について図14を用いて述べる。T1からの認証要求600から、R11でのパス計算606までは、図4で説明した処理と同様である。パス計算606の結果、R11−R12間で要求帯域を確保できなかった場合、パス計算・設定応答630によってRR1に通知する。この際、パス計算・設定応答メッセージ100(図8)内のパス計算結果フィールド101には、”パス計算不成功”を示す値が格納される。
【0053】
上記のパス計算・設定応答メッセージ100を受信したRR1は、パス計算・設定応答メッセージ100内のパス計算結果フィールド101の値を検査し、R11−R12間の帯域確保が不成功だったことを認識する。その後、経路R11−R12を使用する中継サーバS1を候補からはずし、次の中継サーバ候補判定処理631を行う。上記中継サーバ候補判定処理631の結果、次の中継サーバ候補をS2と決定する。この場合、RR1は転送経路の始点ルータR23に対してパス計算・設定要求632を行う。パス計算・設定要求を受信したR23はパス計算633を実行する。これ以降の処理は、図4および図14で説明した処理と同様である。
【0054】
前述した本実施形態によるリクエストルーティングネットワークは、さらに以下に列挙する項目(a)から(i)の特徴点を備える。
【0055】
(a)少なくとも一つの種類のデータのコピーを保持する複数のサーバと、該データを要求する複数の端末と、前記データ要求を前記複数のサーバに対しリダイレクトするリクエストルータとが複数のルータによって相互に接続され、前記リクエストルータは前記データ要求を受けて、前記サーバに対し前記リダイレクトする前に、前記サーバに近接して接続されたルータの1つに対し、前記データを配信する為の新たなパスの計算及び設定を要求することを特徴とするリクエストルーティングネットワーク。
【0056】
(b)上記リクエストルーティングネットワークにおいて、前記リクエストルータは、サーバ選択部、パス設定部及びパス情報管理テーブルを備え、前記サーバ選択部は所定の条件を基に、前記複数のサーバの内、候補と成るサーバを選択し、前記リダイレクトする前に、前記パス設定部は前記複数のルータの内、前記サーバに近接して接続されたルータである最上流ルータに対し前記パスの計算及び設定を要求し、前記計算及び設定の結果に従い、前記パス設定部は前記最上流ルータにより設定された前記新たなパス情報を前記パス情報管理テーブルに格納し、前記設定された前記新たなパスを利用し前記選択されたサーバから前記端末に対し前記要求されたデータを配信することを特徴とする。
【0057】
(c)上記リクエストルーティングネットワークにおいて、前記サーバから前記端末までの遅延時間及び前記サーバの前記データ処理負荷が最小である事を前記所定の条件とし、前記パスは前記最上流ルータから前記端末に近接して接続された最下流ルータまでのルータリストであり、前記リクエストルータが管理する前記ネットワークの負荷として、前記サーバから前記端末までの前記パスにおける前記データ配信時の遅延時間、および前記パスにおける余剰帯域を管理することを特徴とする。
【0058】
(d)上記リクエストルーティングネットワークにおいて、前記リクエストルータが、前記端末からのデータ要求時に、前記パス上に前記データ配信に必要な帯域が確保できない場合、前記リクエストルータは、前記データ配信に必要な前記帯域を前記最上流ルータに通知し、前記最上流ルータは、前記パスの計算及び設定において、前記帯域を基に前記新たなパスを計算し、前記計算の結果、前記新たなパスが設定可能な場合は前記最上流ルータが前記新たなパスを設定し、前記新たなパスの設定を前記リクエストルータに返信し、前記新たなパスの設定通知を受信した前記リクエストルータは、前記新たなパスも考慮してデータ配信に必要なサーバを決定することを特徴とする。
【0059】
(e)上記リクエストルーティングネットワークにおいて、前記リクエストルータが前記データ配信に必要な帯域を前記最上流ルータに通知する際、前記リクエストルータは前記帯域以外の条件を基にして前記データ要求を前記リダイレクトする前記サーバの候補と配信する為のパスを一つ決定し、前記パスに対してデータ転送に必要な帯域が確保可能か検査し、確保できない場合に、前記リクエストルータは前記データ配信に必要な帯域を前記パスの前記最上流ルータに通知することを特徴とする。
【0060】
(f)上記リクエストルーティングネットワークにおいて、前記リクエストルータが前記データ配信に必要な前記帯域を前記最上流ルータに通知する際、前記要求されたデータの配信に必要な最低限の帯域よりも大きな帯域を前記最上流ルータに通知することにより、前記データ要求とは別のデータ要求に対するリクエストルーティング処理の際、新たなパスの計算および設定処理を抑制することを特徴とする。
【0061】
(g)上記リクエストルーティングネットワークにおいて、前記リクエストルータは、前記端末からのデータ要求時に、前記データ配信に必要な前記帯域を確保できない場合、前記パスの前記最上流ルータと前記複数のルータの内、前記端末に隣接して接続されている最下流ルータ間における前記データ配信に必要な前記帯域を確保するための前記新たなパスを計算し、前記計算の結果、前記新たなパスが設定可能な場合は前記新たなパスを設定し、前記設定されたパスの余剰帯域も考慮して前記データ配信に最適なサーバを決定することを特徴とする。
【0062】
(h)上記リクエストルーティングネットワークにおいて、前記パスの前記最上流ルータと前記最下流ルータ間における前記データ配信に必要な前記帯域を確保するための前記新たなパスを計算する際、前記リクエストルータは常時収集している前記新たなパスに対する前記最上流ルータと前記最下流ルータ間のネットワーク接続状態、前記複数のルータの負荷および前記複数のルータ間における回線の余剰帯域を基にしてデータ配信に必要な帯域を確保する前記新たなパスを計算することを特徴とする。
【0063】
(i)上記リクエストルーティングネットワークにおいて、前記リクエストルータが、前記サーバから前記端末までに複数のパスが存在する場合は、前記複数のパス上の余剰帯域を管理し、前記複数のパスを考慮してデータ配信に最適なサーバを決定することを特徴とする。
【0064】
又、上記ネットワークにおいて前述した図4に示すリクエストルーティング処理手順は、以下に列挙する項目(i)から(iv)の特徴点を備えるパス設定方法として提供することも可能である。
【0065】
(i)複数種類のデータのコピーを保持する複数のサーバと、該データを要求する複数の端末と、前記データ要求を前記複数のサーバにリダイレクトするリクエストルータとが複数のルータによって相互に接続されるネットワークにおいて実施されるパス設定方法において、前記端末からの前記データ要求に従い、前記リクエストルータが前記データを所定の条件にて配信しうる前記サーバの候補を決定するステップと、前記複数のルータの内、前記決定された前記サーバに近接したルータに対し、パスの計算及び設定を要求するステップと、前記計算及び設定の結果に従い、前記リクエストルータに新たなパスの情報を追加し、前記サーバに対し前記データ要求をリダイレクトするステップとを含むことを特徴とするパス設定方法。
【0066】
(ii)上記パス設定方法において、前記サーバから前記端末までの遅延時間及び前記サーバの前記データ処理負荷が最小であることを前記所定の条件とし、前記サーバからの前記新たなパスを経由した前記端末に対する前記データ転送の後、前記リクエストルータは前記複数のルータによるパスの使用状況に従い、パスの開放処理を実施するステップを含むことを特徴とする。
【0067】
(iii)上記パス設定方法において、前記複数のルータは、前記端末に近接したルータである最下流ルータを含み、前記要求するステップの後に、前記サーバに近接したルータである最上流ルータにおいて前記パスの計算及び設定を実施し、前記計算の結果、前記最上流ルータ及び最下流ルータを介して前記サーバが前記要求されるデータを前記端末に配信する為に必要となる帯域が確保出来ない場合、該帯域が確保出来ないことを前記リクエストルータに返信し、前記リクエストルータは新たなサーバの候補を決定することを特徴とする。
【0068】
(iv)上記パス設定方法において、前記パスは前記サーバに近接したルータである最上流ルータから前記端末に近接して接続された最下流ルータまでのルータリストであることを特徴とする。
【0069】
次に、本発明のリクエストルータRR1の詳細動作について図1を用いて説明する。入力インターフェース101は、一つ以上のポートを保持し、一つ以上の回線を介して、サーバS1、S2、S3、端末T1、T2、およびルータR11、R12、R13、R21、R22、R23、R31と接続されている。入力インターフェース101は、ネットワーク転送プロトコルの終端を行い、T1、T2から受信したデータ転送要求メッセージや、始点ルータR11、R23から受信したパス計算・設定応答メッセージ、パス開放応答メッセージなどの組み立てを行う。例えば、ネットワーク転送プロトコルとしてTCP(転送制御プロトコル)/IP(インターネットプロトコル)/Ethernet(登録商標)が使用されている場合、入力インターフェース101はEthernet(登録商標)フレームの正常性確認、IPパケットの正常性確認、IPパケットの組み立て、TCPコネクションの終端等を行う。入力インターフェース101は、組み立てたデータ転送要求メッセージ、パス計算・設定応答メッセージ、パス開放応答メッセージをプロトコル解析部102に転送する。
【0070】
[利用者認証]
次に、RR1がT1から認証要求を受信した際の、図4における利用者認証処理601について説明する。図4で説明した例では、入力インターフェース101は、T1との間で通信コネクションの確立を行った後、まず、T1から受信した認証要求メッセージ70をプロトコル解析部102に転送する。
【0071】
プロトコル解析部102は、入力インターフェース101から転送されたユーザ認証要求メッセージ70から、利用者識別子72、利用者パスワード73を抽出し、利用者識別・データアクセス認証処理部111に転送する。利用者識別・データアクセス認証処理部111は、利用者認証に使用する利用者情報テーブル113を保持する。この利用者情報テーブル113の一構成例を図17に示す。
【0072】
図17に示す利用者情報テーブル113の例では、予め正しい利用者識別子200、利用者パスワード201の組み合わせが設定されている。また、利用者情報テーブル113には、利用者が契約によりアクセスを許可されているデータグループを示す契約データグループ識別子202と、利用者が契約した配信品質レベル203、および利用者が使用する端末に最も近い最近接ルータ204が設定されている。ここで、利用者が契約する配信品質レベル203は、データ配信時にどれだけ厳密に品質を保証するかを指定する指標である。利用者情報テーブル113の設定は、制御部107を介してネットワーク管理装置から行ってもよいし、入力インターフェース101とプロトコル解析部102を介してネットワーク管理装置から行ってもよい。
【0073】
利用者の端末に最も近いルータを設定する方法としては、契約時に予め利用者のネットワークアドレスを登録しておき、このネットワークアドレスからRR1がIPルーティングテーブル等を用いて判定する方法がある。別の方法としては、端末からのデータ要求メッセージをペイロードとして格納するIPパケットのヘッダを検査し、ヘッダ内の送信元IPアドレスを抽出し、このIPアドレスからRR1がIPルーティングテーブル等を用いて判定する方法がある。
【0074】
利用者識別・データアクセス認証処理部111は、プロトコル解析部102から受信した図5の利用者識別子72、利用者パスワード73を検索キーとして利用者情報テーブル113(図1)を検索する。そして、利用者認証要求メッセージ70を送信したT1の利用者が正規のユーザであるかを判定し、プロトコル解析部102に結果を通知する。プロトコル解析部102は、利用者識別・データアクセス認証処理部111から受信した利用者認証結果をもとに利用者認証応答メッセージ80(図6)を作成し、出力インターフェース106に送信する。出力インターフェース106は利用者認証応答をネットワーク転送プロトコルに従ってカプセル化し、T1へ送信する。
【0075】
[データ要求受信および中継サーバ候補選択処理]
次に、RR1がT1からデータ要求を受信した際の、図4の中継サーバ候補判定処理604について図1を参照して説明する。入力インターフェース101は、T1から受信したデータ要求メッセージ70(図5)をプロトコル解析部102へ転送する。プロトコル解析部102は、入力インターフェース101から転送されたデータ要求メッセージ70から利用者識別子72、データ識別子74を抽出し、利用者識別・データアクセス認証処理部111へ転送する。
【0076】
[利用者契約内容、最近接ルータ判定]
利用者識別・データアクセス認証処理部111は、プロトコル解析部102から受信した利用者識別子72を検索キーとして利用者情報テーブル113を検索し、利用者が契約している図17のデータグループ識別子202、配信品質レベル203、利用者の端末に最も近い最近接ルータ204を決定する。利用者識別・データアクセス認証処理部111は、データ識別子74(図7)とともにこれらの情報を中継サーバ候補選択部112(図1)へ通知する。
【0077】
[要求データの必要配信帯域、データ容量、コピー先中継サーバ決定]
データ識別子74(図7)と対応するデータグループ識別子、契約配信品質レベルを受信した中継サーバ候補選択部112(図1)は、まず、データ識別子74を検索キーとしてデータ管理テーブル114を検索する。
【0078】
データ管理テーブル114の一構成例を図18に示す。図18のデータ管理テーブル114は、データ識別子210と、そのデータが属するデータグループ識別子211、配信に必要な帯域212、データ容量213、およびコピー先の中継サーバのリスト214から構成される。図18でデータ識別子”d4”で識別されるデータの必要帯域を”−”としているのは、このデータがストリーミング型のデータではなく、一度全データが利用者の端末内に格納されてから利用される蓄積型のデータであることを仮定しているからである。また、データ識別子”d1”、”d2”、”d3”で識別されるデータのデータ容量の設定値を”−”としているのは、これらのデータが蓄積型のデータではなく、ストリーミング型のデータであることを仮定しているためである。
【0079】
中継サーバ候補選択部112(図1)はデータ管理テーブル114を検索し、上記の情報を得る。この内、図18のデータグループ識別子211と、利用者識別・データアクセス認証処理部111から通知された利用者が契約しているデータグループ識別子とを比較する。さらに、図17の契約データグループ識別子202のうち、データグループ識別子211に一致するものがあれば、利用者がそのデータを要求することを許可されたことになる。また、データグループ識別子211のなかに、契約データグループ識別子に一致するものがない場合は、利用者がそのデータを要求することを許可されていないことになる。この場合は、利用者の端末に対してデータ要求拒否メッセージを送信する。
【0080】
[配信経路情報テーブルを逐次検索し、経路および中継サーバの候補決定]
次に、中継サーバ候補選択部112(図1)は、中継サーバ情報テーブル115、配信経路情報テーブル116と、上記までの処理で得られた条件、すなわち図17に示す利用者の契約配信品質レベル203、最近接ルータ204、図18に示すデータ配信に必要な帯域212、データ容量213、コピー先中継サーバ214をもとにして、配信経路と中継サーバの候補を決定する。
【0081】
中継サーバ情報テーブル115(図1)の一構成例を図19に示す。図19の中継サーバ情報テーブル115は、始点ルータ220と中継サーバ識別子221と、中継サーバのMPU負荷222の組み合わせからなる複数のエントリから構成される。各中継サーバのMPU負荷情報は、中継サーバ監視部104(図1)が定期的に収集する。具体的には中継サーバ監視部104が、定期的に各サーバ宛てのサーバ負荷検査メッセージをプロトコル解析部102、出力インターフェース106を介して送信する。サーバ負荷検査メッセージを受信した各サーバは、各サーバのMPU負荷をサーバ負荷応答メッセージに格納してRR1に送信する。サーバ負荷応答メッセージを、入力インターフェース101、プロトコル解析部102を介して受信した中継サーバ監視部104は、サーバ負荷応答メッセージ内の各サーバのMPU負荷を抽出し、中継サーバ情報テーブル115内の該当するサーバのMPU負荷フィールドに上書きする。
【0082】
配信経路情報テーブル116(図1)の一構成例を図20に示す。図20の配信経路情報テーブル116は、終点ルータ230、始点ルータ231、上記の始点ルータ−終点ルータ間に設定されているパスの識別子232、上記パスの確保帯域233、現在の使用帯域234、始点ルータから終点ルータまでの遅延時間235の組み合わせからなる複数のエントリから構成される。遅延時間は始点ルータからではなく、中継サーバからの遅延時間でもよい。各配信経路の使用帯域234、遅延時間235は、配信経路監視部105(図1)が各配信経路の情報を基に定期的に収集する。各配信経路の使用帯域の測定方法としては、配信経路上の各ルータの転送パケット数統計や転送パケットのバイト数統計を取得し計算する方法がある。上記の各々の統計情報の取得には、独自のメッセージを用いてもよいし、SNMP(Simple Network Management Protocolの略)を用いてもよい。また、遅延時間の測定方法としては、RR1が始点ルータあるいは中継サーバに対してpingコマンド発行要求を行い、pingコマンド発行要求を受信した始点ルータあるいは中継サーバが終点ルータに対してpingコマンドを発行して応答時間を測定し、その結果をRR1に送信する、という方式がある。ここで、pingコマンドはパケットの平均応答時間を測定したり、ネットワーク経路のテストを実施する為のコマンドである。
【0083】
本発明の実施例では、要求帯域を満たす経路が現状存在しなくても、新たに帯域を確保できるパスがあるかどうかを計算するという方法を採用する。また、中継サーバ候補を決定する条件として、配信時の遅延時間が小さいことを第一条件とし、中継サーバのMPU負荷が小さいことを第二条件とする。上記の条件を元にして、図1の中継サーバ候補選択部112は、配信経路情報テーブル116の遅延時間235(図20)と、中継サーバ情報テーブル115のMPU負荷222(図19)を参照し、経路候補としてR11−R12を、中継サーバ候補としてS1を選択する。その後、中継サーバ候補選択部112は、配信経路情報テーブル116から経路候補R11−R12上に設定されている図20のパスの確保帯域233と使用帯域234を取得し、データ配信に必要な帯域があるかどうかを検査する。中継サーバ候補選択部112は、使用帯域にデータ配信必要帯域を加算し、上記の加算値が確保帯域よりも小さい場合は、帯域確保のための新たなパス設定は必要ないと判定する。上記の加算値が確保帯域と等しいあるいは大きい場合は、帯域確保のための新たなパス設定が必要であると判定する。本発明の実施例において、T1が要求する図18に示すデータ識別子はd1と仮定すると、データ管理テーブル114から、配信に必要な帯域は5Mbit/secとなる。また、配信経路候補R11−R12間に設定されているパスは図20のパス識別子からp11_12_1のみであり、確保帯域と使用帯域がそれぞれ1Gbit/secである。従って本発明の実施例の場合、中継サーバ候補選択部112は帯域確保のための新たなパス設定が必要と判定する。
【0084】
[パス計算・設定要求メッセージ生成]
経路および中継サーバの候補を選択した図1の中継サーバ候補選択部112は、パス設定処理部103に要求帯域(本発明の実施例の場合、5Mbit/sec)と始点ルータR11を通知する。パス設定処理部103は、上記の情報をプロトコル解析部102に転送する。プロトコル解析部102は、パス設定処理部103から受信した始点ルータR11と要求帯域をもとにパス計算・設定要求メッセージを作成し、出力インターフェース106に送信する。出力インターフェース106はパス計算・設定要求メッセージをネットワーク転送プロトコルに従ってカプセル化し、R11へ送信する。以上、RR1がT1からデータ要求を受信した際の、図4の中継サーバ候補判定処理604について説明した。
【0085】
[パス情報追加処理およびデータ要求リダイレクト処理]
次に、RR1がR11からパス計算・設定応答メッセージ100(図8)を受信する際の、図4のパス情報追加処理612、およびデータ要求リダイレクト613について図1を用いて説明する。入力インターフェース101は、パス計算・設定応答メッセージ100をプロトコル解析部102へ転送する。プロトコル解析部102は、パス計算・設定応答メッセージ100から図8に示すパス計算結果101、パス設定結果102、設定帯域103、パス識別子104を抽出し、パス設定処理部103へ転送する。パス設定処理部103は、パス計算結果101、パス設定結果102に設定されている値から、R11−R12に新たなパスが設定されたことを認識する。その後パス設定処理部103は、設定帯域103、パス識別子104に設定された値を元に配信経路情報テーブル116に新たなエントリを追加する。図21に、上記で説明した新しいエントリを追加された配信経路情報テーブル116の設定例を示す。図20では、エントリ2301、2302の2つのエントリが登録されていたが、図21では、新たにエントリ2303が追加されている。
【0086】
本発明の実施例では、新しいパス上で確保された帯域が、T1からのデータ要求に対して必要な帯域である5Mbit/secよりも大きい200Mbit/secである例を示している。本発明の実施例のように、データ要求に対して当該データの配信に必要な帯域よりも大きな帯域を確保することにより、別のデータ要求に対して、新たに設定したパスも考慮してサーバ候補を決定することが可能になる。従って、データ要求に対して必要な帯域のみを確保する場合に比べて、パス計算時間およびパス設定時間を短くすることが可能になる。また、RR1と各始点ルータ間で転送されるパス計算・設定要求、および応答メッセージのデータ量や、各ルータ間で転送されるパス設定要求、および応答メッセージのデータ量を削減することが可能となる。
【0087】
図1に示す配信経路情報テーブル116へ新たなパス情報を追加した後、パス設定処理部103は中継サーバ候補選択部112に対し、新規パス情報追加処理の完了通知を行う。上記完了通知を受信した中継サーバ候補選択部112は、データ要求の振り向け先の中継サーバとしてS1を選択する。その後、蓄積してあったT1からのデータ要求をプロトコル解析部102に転送する。プロトコル解析部102はT1からのデータ要求を出力インターフェース106に転送し、出力インターフェース106はS1へデータ要求を送信する(ステップ613)(図4)。
【0088】
以上の本実施例の形態によるリクエストルータ装置RR1は、以下に列挙される項目(I)〜(VIII)の特徴点を有するリクエストルータ装置として提供することも可能である。
【0089】
(I)少なくとも1つの入力インターフェース、少なくとも1つの出力インターフェースを有し、前記入力インターフェースおよび出力インターフェースを介して、ネットワーク上に分散配置された複数のサーバ及びルータの負荷、およびネットワークの負荷を管理し、前記ネットワークに接続された端末からのデータ要求受信時に、該データのコピーを保持する前記複数のサーバのうちから、データ配信を行うサーバを決定し、前記端末からのデータ要求を前記決定された前記サーバにリダイレクトするリクエストルータ装置において、前記リクエストルータ装置はパス設定部を含み、前記リダイレクトする前に、前記パス設定部は前記複数のルータの内、前記決定された前記サーバに近接して接続されているルータの1つに対し、前記要求されたデータを配信する為の新たなパスの計算及び設定を要求することを特徴とする。
【0090】
(II)上記リクエストルータ装置において、前記パスは前記サーバに近接して接続されているルータである最上流ルータから前記端末に近接して接続された最下流ルータまでのルータリストであり、前記管理する前記ネットワークの負荷として、前記決定された前記サーバから前記端末までのデータ配信経路における配信時の遅延時間、および前記パスにおける余剰帯域を管理することを特徴とする。
【0091】
(III)上記リクエストルータ装置において、前記サーバから前記端末までのデータ配信パスにおける余剰帯域を管理する配信経路情報テーブルを保持し、前記端末からのデータ要求時に、前記配信経路情報テーブル内に保持されるパス上にデータ配信に必要な帯域が確保できない場合、前記パス設定部は前記データ配信に必要な帯域を前記サーバに近接して接続されているルータである最上流ルータに通知し、該最上流ルータからの前記パスの計算結果およびパス設定結果を受信し、前記パス設定の結果、新しいパスが設定された場合は、前記リクエストルータ装置が有するサーバ選択部が前記パスを考慮してデータ配信に必要なサーバを決定することを特徴とする。
【0092】
(IV)上記リクエストルータ装置において、前記データ配信に必要な帯域を前記最上流ルータに通知する際、前記帯域以外の条件を基にしてデータ要求をリダイレクトするサーバの候補と配信パスを一つ決定し、前記パスに対して前記データ転送に必要な帯域が確保可能か検査し、確保できない場合に、前記データ配信に必要な帯域を前記パスの前記最上流ルータに通知することを特徴とする。
【0093】
(V)上記リクエストルータ装置において、前記データ配信に必要な帯域を前記最上流ルータに通知する際、要求された前記データの配信に必要な最低限の帯域よりも大きな帯域を前記最上流ルータに通知することにより、前記データ要求とは別のデータ要求に対するリクエストルーティング処理時における、前記ネットワーク上の前記ルータにおけるパス計算およびパス設定処理を抑制することを特徴とする。
【0094】
(VI)上記リクエストルータ装置において、前記サーバから前記端末までの前記データ配信パスにおける余剰帯域を管理する配信経路情報テーブルを保持し、前記端末からのデータ要求時に、前記配信経路情報テーブル内に保持されるパス上に前記データ配信に必要な帯域が確保できない場合、前記パスの前記最上流ルータと前記複数のルータの内、前記端末に近接して接続されている最下流ルータ間における前記データ配信に必要な帯域を確保するための前記新たなパスを計算し、前記計算の結果、前記新たなパスが設定可能な場合は前記最上流ルータから最下流ルータまでの間に前記新たにパスを設定し、前記設定した前記パスの余剰帯域も考慮して前記データ配信に最適なサーバを決定することを特徴とする。
【0095】
(VII)上記リクエストルータ装置において、前記配信経路情報テーブル内に保持される前記パスの前記最上流ルータと最下流ルータ間において、回線の接続状態および前記複数のルータの負荷および該回線の余剰帯域を常時収集して管理し、前記パスの前記最上流ルータと最下流ルータ間における前記データ配信に必要な帯域を確保するための前記新たなパスを計算する際に用いることを特徴とする。
【0096】
(VIII)上記リクエストルータ装置において、前記サーバから前記端末までの前記データ配信パスにおける余剰帯域を管理する配信経路情報テーブルを保持し、前記サーバから端末までに複数のパスが存在する場合は、前記複数のパス上の余剰帯域も併せて前記配信経路情報テーブルに登録して管理し、前記複数のパスを考慮して前記データ配信に最適なサーバを決定することを特徴とする。
【0097】
さらに、本発明の図3に示すネットワークのルータR11、R12、R13等の動作機能について、図22に示すルータ装置構成のブロック図に基づいて以下に説明する。
【0098】
始点ルータRxxは、ネットワーク内の他の各ルータから、各ルータが収容するインターフェースの回線帯域、余剰帯域、他のルータとの接続状態等の情報をプロトコル解析部xx−4を経由して経路情報収集部xx−7で抽出し、上記情報を経路情報テーブルxx−8に登録しておく。ここで、本実施例の場合、RxxはR11に該当する。
【0099】
始点ルータRxxは、リクエストルータRR1から入力インターフェースxx−1を介してパス計算・設定要求メッセージを受信すると、プロトコル解析部xx−4でメッセージを解析し、終点ルータと、要求帯域をパス計算処理部xx−5に通知する。パス計算処理部xx−5は、経路情報テーブルxx−8に収集されている情報を基にして、始点ルータと終点ルータ間の経路で、要求帯域を満足する最適なパスを計算する。ここで、上記最適なパスは始点ルータから終点ルータまでのルータのリストであり、図9のルータリスト115に相当する。
【0100】
パス設定処理部xx−6は、パス計算処理部xx−5が計算した最適パス情報(ルータのリスト)を受信し、そのリストをパス設定要求メッセージ110(図9)に格納してプロトコル解析部xx−5に送信する。プロトコル解析部xx−5は上記パス設定要求メッセージをパケット化して、出力インターフェース経由でさらに下流ルータR13等に送信する。
【0101】
前述の本実施例による図22のルータ装置は、以下に列挙される項目(1)から(3)の特徴点を有するルータ装置として提供することが可能である。
【0102】
(1)少なくとも1つの入力回線と少なくとも1つの出力回線を有し、前記入力回線および出力回線を介して、ネットワーク上に配置されるリクエストルータに対しパケットの受信或いは送信を行い、前記ネットワーク上の他の複数のルータから回線の使用帯域などの情報を収集するルータ装置において、前記ルータ装置は、パス計算処理部とパス設定処理部を含み、前記パス計算処理部は前記入力回線を通して、前記リクエストルータから転送される要求メッセージを受信し、前記ルータ装置が有する経路情報テーブルの情報を基にして、パス計算を行い、前記パス設定処理部は前記計算結果に従い、パス設定を行うことを特徴とする。
【0103】
(2)上記ルータ装置において、前記ネットワークには、前記リクエストルータに対しデータを要求する複数の端末が接続され、前記要求メッセージ内に格納されている要求帯域と前記複数のルータの内、前記端末に近接して接続される最下流ルータを識別する識別子をもとにして、前記ルータ装置と前記最下流ルータの間に前記要求帯域を確保可能なパスが存在するかどうかを計算し、前記計算の結果、前記要求帯域を確保可能なパスが存在する場合には、前記最下流ルータに対してパス設定要求メッセージを送信し、前記最下流ルータからパス設定応答メッセージを受信した場合には、前記要求帯域を確保可能なパスが設定されたと認識し、前記リクエストルータに対してパス設定応答メッセージを送信することを特徴とする。
【0104】
(3)上記ルータ装置において、前記ネットワークには、前記端末が要求するデータのコピーを保持する複数のサーバが接続され、前記パスは前記サーバに近接して接続されているルータである最上流ルータから前記最下流ルータまでのルータリストであることを特徴とする。
【0105】
以上では、パス計算はリクエストルータからパス計算・設定要求メッセージを受信した上流ルータ或いは始点ルータRxxが行い、パス設定は各ルータが自律的に実行する本発明の一実施例について説明した。上記の一実施例では、パス計算、およびパス設定をルータに任せることにより、リクエストルータの処理負荷を抑える効果がある。
【0106】
本発明の別の実施例としては、リクエストルータが各経路の周辺のネットワーク構成および各ルータが収容する回線の使用帯域などの情報を常時収集し、上記の情報に基づきデータ配信に必要な帯域を確保可能なパスの計算、およびパス設定を集中的に行ってもよい。
【0107】
【発明の効果】
以上に述べる本発明のリクエストルータ装置、ルータ装置およびリクエストルーティングネットワークを採用することにより、データ要求に対して中継サーバから端末への配信経路上の帯域を動的に制御し、配信経路上の帯域が不足している場合は新たに経路を設定することにより帯域を増加させることが可能となる。
【0108】
従って、サーバ資源、ネットワーク資源の両方を有効利用することができ、同一のサーバ資源、ネットワーク資源を用いても、より多数の利用者に対して高品質のデータ配信サービスを提供することが可能になる。サービスできるユーザ数が増やせることから、利用者一人あたりのサービス料金を低価格に抑えることが可能になる。
【図面の簡単な説明】
【図1】本発明のリクエストルータRR1の一構成例を示す図である。
【図2】従来のリクエストルーティング技術の概要を説明する図である。
【図3】本発明のリクエストルータを適用したネットワークの一構成例を示す図である。
【図4】本発明のリクエストルーティング処理手順の一例を示すフロー図である。
【図5】データ要求メッセージ、認証要求メッセージの一構成例を示す図である。
【図6】データ応答メッセージ、認証応答メッセージの一構成例を示す図である。
【図7】本発明のパス計算・設定要求メッセージの一構成例を示す図である。
【図8】本発明のパス計算・設定応答メッセージの一構成例を示す図である。
【図9】パス設定要求メッセージの一構成例を示す図である。
【図10】パス設定応答メッセージの一構成例を示す図である。
【図11】ルータR12のラベルテーブルの一構成例を示す図である。
【図12】ルータR13のラベルテーブルの一構成例を示す図である。
【図13】ルータR11のラベルテーブルの一構成例を示す図である。
【図14】本発明のリクエストルーティング処理の図4とは異なる手順の一例を示すフロー図である。
【図15】本発明のリクエストルータを適用したネットワークの一構成例におけるデータ配信経路を示す図である。
【図16】従来のリクエストルータを適用したネットワークの一構成例におけるデータ配信経路を示す図である。
【図17】本発明のリクエストルータRR1内に格納される利用者情報テーブルの一構成例を示す図である。
【図18】本発明のリクエストルータRR1内に格納されるデータ管理テーブルの一構成例を示す図である。
【図19】本発明のリクエストルータRR1内に格納される中継サーバ情報テーブルの一構成例を示す図である。
【図20】本発明のリクエストルータRR1内に格納される配信経路情報テーブルの一構成例を示す図である。
【図21】配信経路情報テーブルの図20とは別の設定例を示す図である。
【図22】図3に示すリクエストルーティングネットワークに示すルータR11、R12、R13等の装置構成ブロックを示す図である。
【符号の説明】
S1〜S3…サーバ、R11〜R13、R21〜R23、R3…ルータ、RR1…リクエストルータ、T1〜T2…端末、110…リクエストルーティング処理部、112…中継サーバ候補選択部、103…パス設定処理部、90…パス計算・設定要求メッセージ、100…パス計算・設定応答メッセージ、130、150…ラベルテーブル。
Claims (7)
- 複数のルータ装置からなるネットワークを介して、端末と、それぞれ同一データのコピーを保持する複数のサーバに接続され、上記端末からのデータ要求を上記何れかのサーバに転送するリクエストルータ装置であって、
上記端末からデータ要求を受信する受信部と、
上記データ要求に基づいて、上記複数のサーバのうちから、該データ要求の転送先となるサーバを選択するサーバ選択部とを有し、
上記サーバ選択部が、上記端末と上記選択されたサーバの間に設定されたパス上で、上記データ要求で要求されたデータ配信に必要な帯域が確保できるか否かを判定し、上記パス上では上記データ配信に必要な帯域が確保できない場合、上記複数のルータ装置のうち、上記選択されたサーバに最も近い位置にあるルータ装置に対して、上記選択されたサーバから上記端末にデータ配信するための新たなパスの計算・設定要求を送信し、上記ルータ装置からパス設定に成功したことを示す応答を受信した時、上記データ要求を上記選択されたサーバに転送することによって、
上記データ要求で要求されたデータが、上記新たなパスを経由して、上記選択されたサーバから上記端末に配信されるようにしたことを特徴とするリクエストルータ装置。 - 請求項1に記載のリクエストルータ装置であって、
前記サーバ選択部が、前記各サーバの処理負荷と、前記端末までの配信データの遅延時間とに基いて、前記データ要求の転送先となるサーバを選択することを特徴とするリクエストルータ装置。 - 請求項1に記載のリクエストルータ装置であって、
前記パスの計算・設定要求に対する前記ルータ装置から応答内容に基いて、前記選択されたサーバと前記端末との間に設定されたパスにおける配信データの遅延時間と余剰帯域を管理するパス設定部を有することを特徴とするリクエストルータ装置。 - 請求項1に記載のリクエストルータ装置であって、
前記サーバ選択部が、前記データ配信に必要な帯域以外の条件に基づいて、前記データ要求の転送先となるサーバを選択し、上記選択されたサーバから前記端末へのデータ配信用のパス候補を決定し、該パス候補について前記データ転送に必要な帯域の確保が可能か否かを判定し、必要な帯域が確保できない場合に、上記サーバに最も近いルータ装置に対して、前記パスの計算・設定要求を送信することを特徴とするリクエストルータ装置。 - 請求項1に記載のリクエストルータ装置であって、
前記サーバ選択部が、前記パスの計算・設定要求を送信する際に、前記ルータ装置に対して、前記データ配信で必要となる帯域を指定することを特徴とするリクエストルータ装置。 - 請求項1に記載のリクエストルータ装置であって、
前記サーバ選択部が、前記パスの計算・設定要求を送信する際に、前記ルータ装置に対して、前記データ配信で必要となる帯域よりも大きな帯域の確保を要求することによって、前記データ要求とは別のデータ要求をリクエストルーティングする際に、新たなパス設定の処理時間を短縮することを特徴とするリクエストルータ装置。 - 請求項1〜請求項6の何れかに記載のリクエストルータ装置であって、
前記ルータ装置からパス設定に失敗したことを示す応答を受信した時、前記サーバ選択部が、前記複数のサーバのうちから、前記データ要求の転送先となる別のサーバを選択し、前記端末と上記新たに選択されたサーバの間に設定されたパス上で、上記データ要求で要求されたデータ配信に必要な帯域が確保できるか否かを判定し、上記パス上では上記データ配信に必要な帯域が確保できない場合、上記複数のルータ装置のうち、上記新たに選択されたサーバに最も近い位置にあるルータ装置に対して、パスの計算・設定要求を送信することを特徴とするリクエストルータ装置。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002199550A JP3923863B2 (ja) | 2002-07-09 | 2002-07-09 | リクエストルータ装置 |
US10/357,369 US20040010617A1 (en) | 2002-07-09 | 2003-02-04 | Request routing network system, request router apparatus, router apparatus and a method for path setting in a network |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2002199550A JP3923863B2 (ja) | 2002-07-09 | 2002-07-09 | リクエストルータ装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2004048146A JP2004048146A (ja) | 2004-02-12 |
JP3923863B2 true JP3923863B2 (ja) | 2007-06-06 |
Family
ID=30112469
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2002199550A Expired - Fee Related JP3923863B2 (ja) | 2002-07-09 | 2002-07-09 | リクエストルータ装置 |
Country Status (2)
Country | Link |
---|---|
US (1) | US20040010617A1 (ja) |
JP (1) | JP3923863B2 (ja) |
Families Citing this family (56)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPWO2004073269A1 (ja) * | 2003-02-13 | 2006-06-01 | 富士通株式会社 | 伝送システム,配信経路制御装置,負荷情報収集装置および配信経路制御方法 |
US7382731B1 (en) * | 2003-03-05 | 2008-06-03 | Cisco Technology, Inc. | Method and apparatus for updating probabilistic network routing information |
US7680050B1 (en) | 2003-04-16 | 2010-03-16 | Juniper Networks, Inc. | Distributed admission control |
KR100590863B1 (ko) * | 2003-04-29 | 2006-06-19 | 삼성전자주식회사 | 사설 무선 고속 데이터 시스템에서 단말기 인증 및 호처리 장치 및 그 방법 |
US9525566B2 (en) * | 2003-07-31 | 2016-12-20 | Cloudsoft Corporation Limited | Self-managed mediated information flow |
IL158656A (en) * | 2003-10-29 | 2009-02-11 | Eci Telecom Ltd | Rerouting mpls traffic in ring networks |
US7568047B1 (en) * | 2004-04-30 | 2009-07-28 | Nortel Networks Limited | Method and apparatus for adaptive service label management |
WO2005114492A2 (en) * | 2004-05-21 | 2005-12-01 | Computer Associates Think, Inc. | Method and apparatus for loading data into an alternate evaluator for directory operations |
US7606235B1 (en) | 2004-06-03 | 2009-10-20 | Juniper Networks, Inc. | Constraint-based label switched path selection within a computer network |
US7567512B1 (en) | 2004-08-27 | 2009-07-28 | Juniper Networks, Inc. | Traffic engineering using extended bandwidth accounting information |
US8321573B2 (en) * | 2004-09-17 | 2012-11-27 | Sanyo Electric Co., Ltd. | Communications terminal with optimum send interval |
US7558199B1 (en) * | 2004-10-26 | 2009-07-07 | Juniper Networks, Inc. | RSVP-passive interfaces for traffic engineering peering links in MPLS networks |
JP4514648B2 (ja) * | 2005-05-18 | 2010-07-28 | 富士通株式会社 | 管理サーバによる情報処理方法及びルータ |
US7496037B2 (en) * | 2005-06-14 | 2009-02-24 | International Business Machines Corporation | Apparatus, system, and method for facilitating delivery of asynchronous response messages |
US7720462B2 (en) * | 2005-07-21 | 2010-05-18 | Cisco Technology, Inc. | Network communications security enhancing |
US7961715B1 (en) * | 2005-07-29 | 2011-06-14 | Cisco Technology, Inc. | Technique for reserving resources for authorized entities in a communication network |
JP4168059B2 (ja) | 2006-04-10 | 2008-10-22 | 株式会社日立コミュニケーションテクノロジー | Ponシステムおよび局側装置 |
KR101203461B1 (ko) * | 2006-11-10 | 2012-11-21 | 삼성전자주식회사 | 멀티홉 셀룰러 시스템에서의 라우팅 방법 및 상기 멀티홉셀룰러 시스템 |
FR2909503B1 (fr) * | 2006-12-04 | 2009-10-09 | Alcatel Sa | Procede d'etablissement d'une connexion bidirectionnelle |
US8369213B2 (en) | 2006-12-22 | 2013-02-05 | Cisco Technology, Inc. | Optimization of distributed tunnel rerouting in a computer network with path computation at an intermediate node |
US7693055B2 (en) * | 2006-12-22 | 2010-04-06 | Cisco Technology, Inc. | Optimization of distributed tunnel rerouting in a computer network with intermediate node feedback |
US8472325B2 (en) * | 2007-05-10 | 2013-06-25 | Futurewei Technologies, Inc. | Network availability enhancement technique for packet transport networks |
EP2007102B1 (en) * | 2007-06-21 | 2017-11-22 | Alcatel Lucent | Content-on-demand method and network therefor |
JP4957660B2 (ja) * | 2008-06-20 | 2012-06-20 | 富士通株式会社 | ラベルスイッチングネットワークにおける通信装置 |
US8676760B2 (en) * | 2008-08-05 | 2014-03-18 | International Business Machines Corporation | Maintaining data integrity in data servers across data centers |
US20100166420A1 (en) * | 2008-12-22 | 2010-07-01 | Electronics And Telecommunications Research Institute | Apparatus and method for controlling route and resource in packet-optic convergence network |
US20100191834A1 (en) * | 2009-01-27 | 2010-07-29 | Geoffrey Zampiello | Method and system for containing routes |
US8842533B2 (en) * | 2010-07-02 | 2014-09-23 | Futurewei Technologies, Inc. | Traffic engineering and server selection for content distribution |
KR20120052769A (ko) * | 2010-11-16 | 2012-05-24 | 한국전자통신연구원 | 가상머신을 동기화시키기 위한 장치 및 방법 |
TWI419516B (zh) * | 2010-11-30 | 2013-12-11 | Acer Inc | 具異值網路位址平台的管理方法 |
TWI450103B (zh) * | 2010-12-29 | 2014-08-21 | Acer Inc | 伺服器之遠端管理系統及方法,及其電腦程式產品 |
JP5120471B2 (ja) * | 2011-02-17 | 2013-01-16 | 富士通株式会社 | 情報処理方法及びルータ |
CN103765835B (zh) | 2011-08-30 | 2017-06-20 | 高通股份有限公司 | 混合网络中的拓扑发现 |
US9495326B2 (en) * | 2011-09-12 | 2016-11-15 | Qualcomm Incorporated | Providing communication path information in a hybrid communication network |
CN102388585B (zh) * | 2011-09-19 | 2014-01-08 | 华为技术有限公司 | 网络优化流量控制方法、装置和系统 |
KR101914635B1 (ko) * | 2012-03-16 | 2018-12-28 | 삼성전자주식회사 | 컨텐츠 공유 시스템에서 소스 기기를 결정하기 위한 장치 및 방법 |
US8787400B1 (en) | 2012-04-25 | 2014-07-22 | Juniper Networks, Inc. | Weighted equal-cost multipath |
US9071541B2 (en) | 2012-04-25 | 2015-06-30 | Juniper Networks, Inc. | Path weighted equal-cost multipath |
US9282026B2 (en) * | 2013-03-11 | 2016-03-08 | Dell Products L.P. | System and method for improved routing in autonomous systems |
JP6167587B2 (ja) | 2013-03-21 | 2017-07-26 | 富士通株式会社 | 通信装置、通信ネットワークシステム、通信装置におけるコンテンツサーバ選択方法 |
US20160197840A1 (en) * | 2013-06-19 | 2016-07-07 | Telefonaktiebolaget L M Ericsson (Publ) | Set Up of New Paths Between Border Nodes of a Client Communications Network Through a Server Communications Network |
US9577925B1 (en) | 2013-07-11 | 2017-02-21 | Juniper Networks, Inc. | Automated path re-optimization |
US9992237B1 (en) * | 2014-03-28 | 2018-06-05 | Amazon Technologies, Inc. | Determining feature unavailability |
JP2016005170A (ja) * | 2014-06-18 | 2016-01-12 | 株式会社日立製作所 | 通信システムおよびネットワーク制御装置 |
US9379956B2 (en) * | 2014-06-30 | 2016-06-28 | Nicira, Inc. | Identifying a network topology between two endpoints |
US9553803B2 (en) | 2014-06-30 | 2017-01-24 | Nicira, Inc. | Periodical generation of network measurement data |
US10277512B1 (en) | 2015-02-03 | 2019-04-30 | State Farm Mutual Automobile Insurance Company | Method, device, and computer-readable medium for automatic network traffic engineering |
WO2016153536A1 (en) * | 2015-03-26 | 2016-09-29 | Hewlett Packard Enterprise Development Lp | Delay of route update communication |
US10261690B1 (en) | 2016-05-03 | 2019-04-16 | Pure Storage, Inc. | Systems and methods for operating a storage system |
WO2018168144A1 (ja) * | 2017-03-16 | 2018-09-20 | 住友電気工業株式会社 | 宅側装置及び管理テーブルのクリア方法 |
US10681137B2 (en) | 2017-12-22 | 2020-06-09 | Samsung Electronics Co., Ltd. | System and method for network-attached storage devices |
JP6992611B2 (ja) * | 2018-03-09 | 2022-01-13 | 株式会社デンソー | 中継装置 |
US11868309B2 (en) | 2018-09-06 | 2024-01-09 | Pure Storage, Inc. | Queue management for data relocation |
US12067274B2 (en) | 2018-09-06 | 2024-08-20 | Pure Storage, Inc. | Writing segments and erase blocks based on ordering |
JP7305990B2 (ja) * | 2019-03-12 | 2023-07-11 | 富士通株式会社 | 転送プログラム、転送方法、および情報処理装置 |
CN113301126B (zh) * | 2021-05-06 | 2024-03-12 | 中国南方电网有限责任公司 | 一种适用于异构组网网关的边缘计算方法 |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6084858A (en) * | 1997-01-29 | 2000-07-04 | Cabletron Systems, Inc. | Distribution of communication load over multiple paths based upon link utilization |
US6327622B1 (en) * | 1998-09-03 | 2001-12-04 | Sun Microsystems, Inc. | Load balancing in a network environment |
JP4150159B2 (ja) * | 2000-03-01 | 2008-09-17 | 富士通株式会社 | 伝送経路制御装置及び伝送経路制御方法並びに伝送経路制御プログラムを記録した媒体 |
JP4489925B2 (ja) * | 2000-11-02 | 2010-06-23 | 富士通株式会社 | ネットワーク共有帯域割当て方法及びこれを用いるネットワークシステム |
EP1249973B1 (en) * | 2001-02-23 | 2006-12-06 | Nippon Telegraph and Telephone Corporation | Bandwidth management apparatus and method, program therefor and recording medium with the program recorded thereon |
US6854013B2 (en) * | 2001-06-25 | 2005-02-08 | Nortel Networks Limited | Method and apparatus for optimizing network service |
US8930486B2 (en) * | 2001-09-26 | 2015-01-06 | Intel Corporation | System and method for a centralized intelligence network |
-
2002
- 2002-07-09 JP JP2002199550A patent/JP3923863B2/ja not_active Expired - Fee Related
-
2003
- 2003-02-04 US US10/357,369 patent/US20040010617A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
JP2004048146A (ja) | 2004-02-12 |
US20040010617A1 (en) | 2004-01-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3923863B2 (ja) | リクエストルータ装置 | |
US9819540B1 (en) | Software defined network controller | |
EP2747355B1 (en) | Aggregation network with centralized control | |
CN1992676B (zh) | 在通信网络中多个业务路径之间共享转发状态的方法和设备 | |
Yi et al. | Adaptive forwarding in named data networking | |
EP2680540B1 (en) | Feedback Loop for Service Engineered Paths | |
Chanda et al. | Content based traffic engineering in software defined information centric networks | |
US7180866B1 (en) | Rerouting in connection-oriented communication networks and communication systems | |
JP3701476B2 (ja) | データ通信方法 | |
US11750464B2 (en) | Global network state management | |
KR101317969B1 (ko) | 링크 애그리게이션 방법 및 노드 | |
JP3985638B2 (ja) | Rsvp代理応答ルータ、rsvp代理応答システム及びそれに用いるrsvp代理応答方法 | |
US20050010685A1 (en) | Method and a system for enabling data to be stored in a computer network; a method and a system for storing data in a computer network | |
WO2011162215A1 (ja) | 通信システム、制御装置、ノードの制御方法およびプログラム | |
US20070133570A1 (en) | System and/or method for bidding | |
US20070133571A1 (en) | Bidding network | |
Bryskin et al. | Policy-enabled path computation framework | |
JP3923908B2 (ja) | 通信品質管理システムおよび方法 | |
Egilmez et al. | Openqos: Openflow controller design and test network for multimedia delivery with quality of service | |
JP2005005836A (ja) | ネットワーク及びサーバの負荷低減ルータ | |
EP2216940A1 (en) | Method, system and device for switching source | |
Wahanani et al. | Performance analysis of video on demand and video streaming on the network MPLS Traffic Engineering | |
Kodialam et al. | Online multicast routing with bandwidth guarantees: a new approach using multicast network flow | |
Lin et al. | A QoS model of Next Generation Network based on MPLS | |
CN100456731C (zh) | 不同承载层网络互通中保证业务QoS的方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050314 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20061102 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20061107 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070109 |
|
RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20070109 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070130 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070222 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
LAPS | Cancellation because of no payment of annual fees |