JP3725424B2 - サービス割り当て装置 - Google Patents
サービス割り当て装置 Download PDFInfo
- Publication number
- JP3725424B2 JP3725424B2 JP2000568226A JP2000568226A JP3725424B2 JP 3725424 B2 JP3725424 B2 JP 3725424B2 JP 2000568226 A JP2000568226 A JP 2000568226A JP 2000568226 A JP2000568226 A JP 2000568226A JP 3725424 B2 JP3725424 B2 JP 3725424B2
- Authority
- JP
- Japan
- Prior art keywords
- service
- network
- information
- service request
- rsvp
- 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
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/18—End to end
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/10—Flow control; Congestion control
- H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
- H04L47/2425—Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
-
- 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/781—Centralised allocation of resources
-
- 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/805—QOS or priority 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
Description
技術分野
本発明はサービス割り当て装置に関し、特にネットワークに存在するさまざまな仕様を持ったネットワーク構成装置の中でサービス要求に対応したサービスを提供することができない装置に対して適当なサービスを割り当てることによりネットワーク全体にて相当のサービス保証を行うことが可能になるサービス割り当て装置に関する。
背景技術
近年、ネットワークにおいては多様なサービスが提供されている。その中に、外部装置からのサービス要求を処理してその要求に応えるというサービスが存在する。しかし、ネットワーク構成装置の中には、ある特定のサービス要求を受け取っても処理を行うことができないために、サービス提供機能を有しているにも拘らず、その特定のサービスを提供できない装置が存在する。しかし、すべてのネットワーク構成装置をそのようなサービス要求に対応したものに切り替えることは現実的ではなく、限りあるネットワーク資源を有効に活用することが望まれている。
ここで、特定のネットワーク構成機器が提供するサービス制御として、帯域保証（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御および優先度（ＣｏＳ：Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ）制御が知られている。
帯域保証制御は、たとえばテレビ会議の場合のように、途中で映像データあるいは音声データが途切れたり遅延したりするることがないようエンド・ツー・エンドでサービス品質を動的に保証するものある。この動的に帯域保証制御を行うプロトコルとして、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）プロトコルがＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）において標準化されている。これに対し、優先度制御は、あらかじめ設定された優先度に従ってサービスを提供する静的なサービスである。
ここで、このような異なるサービスを提供するネットワーク構成装置がエンド・ツー・エンドで混在する場合の動作について説明する。
図１９は従来のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。ここでは、たとえば、サービス要求者が、帯域を予約するＲＳＶＰプロトコルを用いて通信経路の帯域予約サービスを受けようとした場合を示している。この図において、たとえばクライアント・サーバシステムのサーバとする送信者１０１とクライアントとする受信者１０２とをネットワークによって接続した通信経路上に、ＲＳＶＰプロトコルに対応した対応ルータ１０３、ＲＳＶＰプロトコルに未対応の非対応ルータ１０４、および対応ルータ１０５の三つのネットワーク構成装置が存在しているとする。この例では、通信経路上の対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５で構成されるネットワークが帯域予約を提供することがサービスとなる。
まず、図１９の（Ａ）に示した第１段階では、送信者１０１から受信者１０２に対して経路指定メッセージ（Ｐａｔｈメッセージ）が送信される。経路指定メッセージは、対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５を介して受信者１０２に届く。このとき、対応ルータ１０３，１０５は経路情報を記憶する。
次に、図１９の（Ｂ）に示した第２段階では、受信者１０２は、送信者１０１までの経路に対して帯域予約の要求を行うために帯域予約要求メッセージ（Ｒｅｓｖメッセージ）を送信する。対応ルータ１０５および対応ルータ１０３においては、それぞれ帯域予約要求に対して自己判断を下して帯域予約を実行する。非対応ルータ１０４においては、帯域予約を実行することができないので、帯域予約要求を処理しないで、そのまま帯域予約要求メッセージを次の対応ルータ１０３に転送する。
そして、図１９の（Ｃ）に示した第３段階では、送信者１０１は、受信者１０２に対してデータ送信を行う。ここで、対応ルータ１０３，１０５は帯域予約ができているので帯域予約を提供できているが、非対応ルータ１０４においては帯域予約ができていない。その結果、送信者１０１から受信者１０２までの通信経路において帯域予約は提供できていないことになり、送信者１０１から受信者１０２に対して帯域予約サービスの提供を行うことができない。したがって、送信者１０１からのデータは、部分的に欠落した状態で受信者１０２に届くなどの問題が発生する。
このように、通信経路上にサービス要求を処理できない装置があった場合、その装置では、サービス要求は理解されずに無視されるため、サービスを提供させることはできない。このため、サービス要求に対して、ネットワーク全体にてサービスが提供不可能となることがある。
図２０は従来の別のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。この構成例は、帯域予約要求に対して帯域予約をしていいかどうかの判断をルータ自身が行うのではなく、ネットワークに関連したポリシを管理しているポリシサーバ１０６が行う場合を示している。この例においても、通信経路上の対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５で構成されるネットワークが帯域予約を提供することがサービスとなる。
まず、図２０の（Ａ）に示した第１段階では、送信者１０１から受信者１０２に対して経路指定メッセージが送信され、対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５を経由して受信者１０２に届く。それぞれＲＳＶＰに対応した対応ルータは経路情報を記憶する。
次に、図２０の（Ｂ）に示した第２段階では、受信者１０２は、送信者１０１までの経路に対して帯域予約の要求を行うために帯域予約要求メッセージを送信する。対応ルータ１０５および対応ルータ１０３においては、それぞれが帯域予約要求を受けると、ポリシサーバ１０６に対して帯域予約許可をＣＯＰＳ（Ｃｏｍｍｏｎ Ｏｐｅｎ Ｐｏｌｉｃｙ Ｓｅｒｖｉｃｅ）プロトコルにて要求を行う。このＣＯＰＳは、ＩＥＴＦのＲＡＰ−ＷＧ（ＲＳＶＰ Ａｄｍｉｓｓｉｏｎ Ｐｏｌｉｃｙ Ｗｏｒｋ Ｇｒｏｕｐ）にて提案された、ＲＳＶＰなどの帯域予約の際に用いられるアドミッション制御（予約の許可・不許可を決定する制御）をポリシに基づいて行うプロトコルである。
ポリシサーバ１０６は持っているポリシから帯域予約許可判断を行って、その判断結果をアドミッション要求を出した対応ルータ１０５，１０３に返す。ここでは、それぞれ予約許可が判断されたものとし、対応ルータ１０５および対応ルータ１０３において帯域予約がなされたものとする。非対応ルータ１０４においては、帯域予約を実行することができないので、帯域予約要求を処理しないで、そのまま帯域予約要求メッセージを次の対応ルータ１０３に転送する。
そして、図２０の（Ｃ）に示した第３段階では、送信者１０１は、受信者１０２に対してデータ送信を行う。ここで、対応ルータ１０３，１０５は帯域予約ができているので帯域予約を提供できているが、非対応ルータ１０４においては帯域予約ができていない。
この結果、ポリシサーバ１０６がネットワークに存在していても、帯域予約許可判断を下すだけであるので、非対応ルータ１０４に対して何か動作を行うものではない。したがって、送信者１０１から受信者１０２に対して帯域予約サービスの提供を行うことができないという問題点があった。
本発明はこのような点に鑑みてなされたものであり、ネットワーク構成装置の中でサービス要求に対応したサービスを提供することができないサービス非対応装置に、適切なサービスを設定することにより、ネットワーク全体でサービスを保証することができるサービス割り当て装置を提供することを目的とする。
発明の開示
すなわち本発明は、ネットワークサービス要求を受け付けて要求されたネットワークサービスを提供することができるサービス要求対応装置からネットワークサービス提供状態情報を知って、外部装置からネットワークサービス設定が可能であって設定されたネットワークサービスを提供することができるサービス要求非対応装置に対してネットワークサービス設定を行うサービス割り当て装置において、前記サービス要求対応装置のネットワークサービス提供状態情報を収集するネットワーク情報収集手段と、前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報を基に前記サービス要求対応装置が提供しているネットワークサービスを提供することができないサービス要求非対応装置を決定する設定装置決定手段と、前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報と前記設定装置決定手段が決定したサービス要求非対応装置の情報とを基に前記サービス要求非対応装置に設定すべきサービスの決定を行うサービスマッピング手段と、前記サービス要求非対応装置に前記サービスマッピング手段で決定されたサービスを設定するサービス設定手段と、を備えていることを特徴とするサービス割り当て装置が提供される。
設定装置決定手段は、ネットワーク情報収集手段がサービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納するとともに設定装置決定手段がサービス要求非対応装置を決定するデータに反映させる動的ネットワーク情報テーブルを有することができる。
このサービス割り当て装置は、さらに、サービス要求対応装置からこのサービス要求対応装置が受け付けたネットワークサービス要求に対してネットワークサービスを提供するかどうかの許可判断の問い合わせを受けて、ネットワークサービス提供の許可判断を下し、判断結果をサービス要求対応装置に通知するとともに許可情報をサービス要求対応装置のネットワークサービス提供状態情報として設定装置決定機能に通知するネットワークサービス提供許可判断手段を備えている。
設定装置決定手段は、また、ネットワーク情報収集手段がサービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納し、設定装置決定手段がサービス要求非対応装置を決定するデータに反映させるとともにネットワーク情報をネットワークサービス提供の許可判断用のデータとする動的ネットワーク情報テーブルを有することができる。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
図１は本発明によるサービス割り当て装置の原理的構成を示すブロック図である。
図２はネットワーク構成装置の配置図である。
図３は第１の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図４は第１の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図５は第１の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
図６は帯域予約判断ポリシテーブルの一例を示す図である。
図７は経路情報テーブルの一例を示す図である。
図８はサービスマッピングテーブルの一例を示す図である。
図９は第２の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１０は第２の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１１は第３の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１２は第３の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１３は第２の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
図１４は動的ネットワーク情報テーブルの一例を示す図である。
図１５は第４の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１６は第４の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１７は第５の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１８は第６の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１９は従来のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。
図２０は従来の別のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。
発明を実施するための最良の形態
まず、本発明の概略について図面を参照して説明する。
図１は本発明によるサービス割り当て装置の原理的構成を示すブロック図である。サービス割り当て装置１０は、ネットワーク構成装置であるサービス要求対応装置２０およびサービス要求非対応装置３０に接続されている。サービス割り当て装置１０は、ネットワーク情報収集手段１１と、設定装置決定手段１２と、サービスマッピング手段１３と、サービス設定手段１４とを備えている。
ここで、サービス要求対応装置２０は、ネットワークサービス要求を受け付け、受け付けたネットワークサービスを提供する機能、およびサービス割り当て装置１０にサービス提供状態情報を与える機能を有している。また、サービス要求非対応装置３０は、ネットワークサービス要求を受け付けるが、その要求に対する処理は行わない。しかし、サービス要求非対応装置３０は、外部装置からサービス設定要求を受け付け、設定を行う機能、および設定されたサービスを提供する機能を有している。
サービス割り当て装置１０において、ネットワーク情報収集手段１１は、サービス要求対応装置２０からサービス提供状態情報を収集する機能を有し、設定装置決定手段１２は、ネットワーク情報収集手段１１が収集したサービス提供状態情報からサービス設定すべきサービス要求非対応装置を決定する機能を有し、サービスマッピング手段１３は、ネットワーク情報収集手段１１が収集したサービス提供状態情報および設定装置決定手段１２が決定したサービス要求非対応装置のデータを用いてサービスマッピング、すなわちサービス設定項目の決定および設定値の変換を行うネットワーク情報・サービス設定連携機能を有し、サービス設定手段１４は、サービスマッピング手段１３から通知されたサービス設定情報を設定装置決定手段１２によって決定されたサービス要求非対応装置３０に対して設定を行う機能を有している。
以上の構成において、まず、サービス要求対応装置２０は、ネットワークサービス要求を受けて、その要求に対する処理をして、サービスを提供する。そのサービス提供状態情報は、サービス割り当て装置１０のネットワーク情報収集手段１１により収集され、さらに設定装置決定手段１２およびサービスマッピング手段１３へ通知される。
設定装置決定手段１２は、ネットワーク情報収集手段１１から受け取ったサービス提供状態情報を基に、ネットワークサービス要求を処理することができないサービス要求非対応装置３０を決定し、決定内容をサービスマッピング手段１３へ通知する。サービスマッピング手段１３は、ネットワーク情報収集手段１１から受け取ったサービス提供状態情報と設定装置決定手段１２から受け取った決定内容とを基にして、サービス要求非対応装置３０に設定すべきサービスを決定し、そのデータをサービス設定手段１４に通知する。そして、サービス設定手段１４は、サービスマッピング手段１３から受け取ったデータをサービス要求非対応装置３０に設定する。
これにより、ネットワークサービス要求に対して処理ができないためにサービスを提供することができないサービス要求非対応装置３０に対して、サービス要求対応装置２０と同じ、あるいは対応したサービスの提供を行わせることができる。すなわち、サービス要求非対応装置３０が有する固有のサービスを割り当てることができ、サービス要求非対応装置３０においてもサービス提供が可能となる。
また、サービス割り当て装置１０は、サービス要求対応装置２０がネットワークサービス要求を受けたときに、要求されたサービスを提供するかどうかの許可の決定を行うサービス提供許可判断手段を備えている。
これにより、サービス要求対応装置２０は、ネットワークサービス要求を受けると、サービス割り当て装置１０に対して、サービス提供の許可不許可の決定の委託を行う。サービス割り当て装置１０では、サービス提供許可判断手段がサービス要求対応装置２０からのサービス提供の許可不許可の決定要求を受け付け、受け付けたサービス提供の許可不許可の決定要求に対して、記憶している判断データから決定を下す。サービス提供許可判断手段は、そのサービス提供の許可不許可の決定をサービス要求対応装置２０に与えると、サービス要求対応装置２０は、許可不許可決定の結果を受けて、サービス提供をするしないを実行する。
設定装置決定手段１２は、サービス提供許可判断手段が受け付けたサービス提供の許可不許可の決定要求からサービス提供情報を知り、サービス設定すべきサービス要求非対応装置３０を決定し、決定内容をサービスマッピング手段１３へ通知する。サービスマッピング手段１３は、サービス提供許可判断手段から受け取ったサービス提供状態情報と設定装置決定手段１２から受け取った決定内容とを基にして、サービス要求非対応装置３０に設定すべきサービスを決定し、そのデータをサービス設定手段１４に通知する。そして、サービス設定手段１４は、サービスマッピング手段１３から受け取ったデータをサービス要求非対応装置３０に設定する。
このように、サービス割り当て装置１０は、サービス提供許可判断手段を備えたことにより、サービス要求対応装置２０からのサービス提供の許可不許可の決定要求に対応する事ができる。
さらに、サービス割り当て装置１０のネットワーク情報収集手段１１は、サービス要求対応装置２０およびサービス要求非対応装置３０からそれらの設定や装置の状態を知ることができるネットワーク状態監視手段を備えている。
これにより、サービス割り当て装置１０では、サービス提供許可判断手段は、受け付けたサービス提供の許可不許可の決定要求に対して、ネットワーク状態監視手段が知ったネットワーク状態から決定を下す。
これにより、ネットワーク状態がサービスを提供できない状態であってもサービス提供許可判断手段はサービス提供の許可不許可の決定要求に対応して許可を出す可能性があったが、許可不許可の判断材料にネットワーク状態の情報を用いることにより、サービス要求対応装置２０に対して、ネットワーク状態を考慮して、適切なサービス提供の許可不許可の決定を通知することができる。
さらに、設定装置決定手段１２は、ネットワーク情報収集手段１１で集めた各ネットワークの状態情報を受け取ってサービス要求非対応装置３０を決定するようにすることができる。これにより、ネットワーク状態によってサービス要求非対応装置３０の位置が動的に変化する場合には、設定装置決定手段１２はサービス要求非対応装置３０の決定にネットワーク状態の情報を用いることが可能なため、ネットワーク状態によるサービス要求非対応装置３０の位置変化にも対応して、サービス要求非対応装置３０の位置決定をすることができる。
次に、本発明の実施の形態を、ポリシサーバに適用した場合を例にして説明する。サービスは、通信の品質に関する帯域予約サービス、セキュリティに関するアクセス認証サービス、プログラムやデータの転送に関する資源配布サービスなど様々であるが、以下では、サービス要求者がＲＳＶＰプロトコルを用いてエンド・ツー・エンド通信に対して帯域予約を求め、ネットワークが要求された通信に対して帯域を予約する帯域予約サービスを例に挙げる。
図２はネットワーク構成装置の配置図である。図２において、クライアント４１およびサーバ４２は、たとえば二つのルータ５０，７０によって構成されるデータ伝達媒体であるネットワークによって接続されており、通信経路上のこれら二つのルータ５０，７０には、ポリシサーバ８０が接続されている。ここで、クライアント４１はサービス要求者であり、サーバ４２はデータ送信者である。また、ルータ５０はＲＳＶＰ資源予約要求を受け付けて資源予約を提供することができるＲＳＶＰ対応のルータであり、ルータ７０はＲＳＶＰ資源予約要求を受け付け処理することができないが、外部から設定された制御情報に従ってサービス提供を行うことができるＲＳＶＰ非対応のルータである。ポリシサーバ８０はルータ５０の帯域予約情報を基にＲＳＶＰ非対応のルータ７０に適切な設定情報を割り当てるサービス割り当て装置として機能する。なお、説明を簡単にするため、クライアント４１を装置Ａ、ルータ５０を装置Ｂ、ルータ７０を装置Ｃ、サーバ４２を装置Ｄと表記することもある。また、各装置間の信号の詳細については、以下の各実施の形態にて説明する。
まず、第１の実施の形態について説明するが、この第１の実施の形態にて使用される各装置の構成を説明する。
図３は第１の実施の形態におけるポリシサーバの構成例を示すブロック図、図４は第１の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図、図５は第１の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図３に示したように、ＳＮＭＰ受信部８１と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０から帯域予約情報ｅを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。
ＲＳＶＰ対応のルータ５０は、図４に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、Ｒｅｓｖメッセージ送信部５６と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３と、帯域予約判断ポリシテーブル６４とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、許可と判断した場合にＳＮＭＰ送信部６３はポリシサーバ８０に対して帯域予約情報ｅを送信する。
ＲＳＶＰ非対応のルータ７０は、図５に示したように、Ｐａｔｈメッセージ受信部７１と、Ｐａｔｈメッセージ送信部７２と、Ｒｅｓｖメッセージ受信部７３と、Ｒｅｓｖメッセージ送信部７４と、ＳＮＭＰ受信部７５と、帯域予約項目設定部７６と、サービスマッピング部７７と、帯域予約実行部７８とから構成されている。Ｐａｔｈメッセージ受信部７１はサーバ４２からのＰａｔｈメッセージａを受け、Ｐａｔｈメッセージ送信部７２はＲＳＶＰ対応のルータ５０に対してＰａｔｈメッセージｂを送信し、Ｒｅｓｖメッセージ受信部７３はＲＳＶＰ対応のルータ５０からのＲｅｓｖメッセージｉを受け、Ｒｅｓｖメッセージ送信部７４はサーバ４２に対してＲｅｓｖメッセージｊを送信し、ＳＮＭＰ受信部７５はポリシサーバ８０からの設定情報ｈを受ける。
次に、以上の構成を有するネットワーク構成装置の動作について説明する。
まず、データ送信者であるサーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をすることができないので、そのままＰａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、帯域予約判断部５８にて帯域予約判断を行う。その際には、帯域予約判断ポリシテーブル６４が用いられる。この帯域予約判断ポリシテーブル６４の例を図６に示す。
図６は帯域予約判断ポリシテーブルの一例を示す図である。この帯域予約判断テーブルは、少なくともユーザ名および最大帯域予約量のフィールドを持ち、各ユーザが予約することができる最大帯域量を定義している。この帯域予約判断テーブルは、帯域予約判断部５８が要求された帯域を予約していいかどうかの許可判断を行うときの判断材料として参照される。
さて、帯域予約判断部５８では、Ｒｅｓｖメッセージ受信部５４からのＲｅｓｖメッセージｄと帯域予約判断ポリシテーブル６４とから帯域予約判断を行う。すなわち、帯域予約判断ポリシテーブル６４の帯域予約ポリシによると、ユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約は「５Ｍｂｐｓ」なので、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていない。したがって、帯域予約判断部５８は帯域予約の許可を行うことになる。
帯域予約の許可の場合には、Ｒｅｓｖメッセージ送信部５６がＲＳＶＰプロトコルのＲｅｓｖメッセージｉにてＲＳＶＰ非対応のルータ７０に送信する。もし、帯域予約が不許可であれば、帯域予約判断部５８は不許可情報ｎをクライアント４１に通知する。ここでは、帯域予約判断部５８は帯域予約の許可を行うので、次に、帯域予約項目設定部６０が帯域予約項目の設定を行う。すなわち、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行う。そして、帯域予約実行部６２は、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。また、帯域予約実行をした後に、その帯域予約情報をＳＮＭＰ送信部６３に通知しておく。ＳＮＭＰ送信部６３は、帯域予約情報ｅをポリシサーバ８０へ通知する。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３にてＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、これを処理できないので、そのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊを送信する。
一方、ポリシサーバ８０は、帯域予約情報ｅをＳＮＭＰ受信部８１にて受け付け、帯域予約の情報を得て、ＲＳＶＰ対応のルータ５０で予約が行われたことを認識する。その帯域予約の情報は、設定装置決定部８４とサービスマッピング部８６とに渡される。設定装置決定部８４は、帯域予約の情報の中に含まれる経路情報と経路情報テーブル８３に設定されているネットワーク情報のデータとからＲＳＶＰ非対応のルータ７０の位置を決定する。ここで、経路情報テーブル８３の例を図７に示す。
図７は経路情報テーブルの一例を示す図である。この経路情報テーブルは、装置名と経路上の次の装置とのフィールドを有し、ネットワーク上のあるネットワーク構成装置に対して経路上の次のネットワーク構成装置があらかじめ定義されている。装置名としては、ネットワーク上の位置情報であるたとえばＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）アドレスが使用される。
設定装置決定部８４は、帯域予約の情報と経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。この場合、図７のあらかじめ与えられた経路情報テーブル８３を見ると、ルータ５０の次はルータ７０なので、ＲＳＶＰ非対応のルータ７０が決定される。設定装置決定情報は、サービスマッピング部８６に渡され、サービスマッピング部８６は設定装置決定情報とＳＮＭＰ受信部８１から得た帯域予約の情報とを基にして、サービスマッピングテーブル８５からＲＳＶＰ非対応のルータ７０に設定すべき値を決定する。ここで、サービスマッピングテーブル８５の例を図８に示す。
図８はサービスマッピングテーブルの一例を示す図である。サービスマッピングテーブルは、ユーザ名、帯域予約量、および優先度割り当てのフィールドを持ち、各ユーザが要求した帯域予約サービスに対して妥当であると思われる優先度のサービスを定義した変換テーブルである。
サービスマッピング部８６は、ＳＮＭＰ受信部８１で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、サービスマッピングテーブル８５を参照すると、それに対応する優先度割り当ては「３」であることが分かるので、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当て、装置設定部８７がＲＳＶＰ非対応のルータ７０に優先度「３」の割り当てを決定する。この情設は、ＳＮＭＰ送信部８８に渡され、設定情報ｈとしてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
以上のようにして、第１の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかを帯域予約判断ポリシテーブル６４に基づき自身で判断して帯域予約を実行し、その帯域予約情報をポリシサーバに通知する。ポリシサーバ８０では、通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。これにより、ＲＳＶＰ未対応のルータにも相当のサービスを動的に設定することができるようになる。したがって、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在したネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
次に、第２の実施の形態について説明するが、この第２の実施の形態にて使用される各装置の構成を説明する。ただし、ＲＳＶＰ非対応のルータ７０は第１の実施の形態のものと同じであるので、ポリシサーバ８０およびＲＳＶＰ対応のルータ５０のみを示す。
図９は第２の実施の形態におけるポリシサーバの構成例を示すブロック図、図１０は第２の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図９に示したように、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信し、ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
ＲＳＶＰ対応のルータ５０は、図１０に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、アドミッション要求部５５と、Ｒｅｓｖメッセージ送信部５６と、ＣＯＰＳ受信部５７と、帯域予約判断部５８と、ＣＯＰＳ送信部５９と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、ＣＯＰＳ受信部５７はポリシサーバ８０からのアドミッション結果情報ｇを受け、ＣＯＰＳ送信部５９はポリシサーバ８０に対してアドミッション要求データｆを送信する。
次に、図９、図１０および図５に示したネットワーク構成装置の動作について説明する。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、そのままＰａｔｈメッセージ送信部７２にてＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１にＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ったＲＳＶＰ対応のルータ５０は、そのデータをアドミッション要求部５５に渡す。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１はあらかじめ与えられた帯域予約判断ポリシテーブル８９を基に帯域予約許可の判断を行う。帯域予約判断ポリシテーブル８９が図６に示したテーブルと同じであるとすれば、帯域予約許可判断部９１はこの帯域予約判断ポリシテーブル８９からユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約が「５Ｍｂｐｓ」であることから、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていないため、帯域予約を許可する決定を行う。帯域予約許可判断部９１によるアドミッション結果情報ｇはＣＯＰＳ送信部９２にてＲＳＶＰ対応のルータ５０へ送信される。
また、帯域予約許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、許可内容とあらかじめ与えられた経路情報テーブル８３の内容とからＲＳＶＰ非対応のルータ７０の位置を決定する。ここで、あらかじめ与えられた経路情報テーブル８３が図７の経路情報テーブルであるとすれば、ルータ５０の次はルータ７０であるので、ＲＳＶＰ非対応のルータ７０が決定される。ルータ７０の決定情報は、サービスマッピング部８６に渡され、そこでサービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とを基にルータ７０に設定するべき値が決定される。図８に示したサービスマッピングテーブルがポリシサーバ８０のサービスマッピングテーブル８５だとすると、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、装置設定部８７は、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定を行う。この設定情報は、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
以上のようにして、第２の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断をポリシサーバ８０に委託する。ポリシサーバ８０は、帯域予約判断ポリシテーブル８９を基に予約許可の判断をし、その結果をＲＳＶＰ対応のルータ５０に通知するとともに、許可の場合は、許可判断の際に通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。許可判断の結果を受け取ったルータ５０は、許可の場合は、帯域予約を実行するようにした。これにより、ポリシサーバ８０は、帯域予約の許可判断を行うアドミッション制御の際に受け取った情報を基にサービス要求に対応していない経路上のルータ７０を決定してそのルータにサービスを割り当てることができ、しかもサービスの一元管理をすることができる。
次に、第３の実施の形態について説明するが、この第３の実施の形態にて使用される各装置の構成を説明する。
図１１は第３の実施の形態におけるポリシサーバの構成例を示すブロック図、図１２は第３の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図、図１３は第２の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図１１に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０からネットワーク情報ｋおよびＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信し、ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
ＲＳＶＰ対応のルータ５０は、図１２に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、アドミッション要求部５５と、Ｒｅｓｖメッセージ送信部５６と、ＣＯＰＳ受信部５７と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信する。そして、ＣＯＰＳ受信部５７はポリシサーバ８０からのアドミッション結果情報ｇを受け、ＣＯＰＳ送信部５９はポリシサーバ８０に対してアドミッション要求データｆを送信し、ＳＮＭＰ送信部６３はポリシサーバ８０に対してネットワーク情報ｋを送信する。
ＲＳＶＰ非対応のルータ７０は、図１３に示したように、Ｐａｔｈメッセージ受信部７１と、Ｐａｔｈメッセージ送信部７２と、Ｒｅｓｖメッセージ受信部７３と、Ｒｅｓｖメッセージ送信部７４と、ＳＮＭＰ受信部７５と、帯域予約項目設定部７６と、サービスマッピング部７７と、帯域予約実行部７８と、ＳＮＭＰ送信部７９とから構成されている。Ｐａｔｈメッセージ受信部７１はサーバ４２からのＰａｔｈメッセージａを受け、Ｐａｔｈメッセージ送信部７２はＲＳＶＰ対応のルータ５０に対してＰａｔｈメッセージｂを送信する。Ｒｅｓｖメッセージ受信部７３はＲＳＶＰ対応のルータ５０からのＲｅｓｖメッセージｉを受け、Ｒｅｓｖメッセージ送信部７４はサーバ４２に対してＲｅｓｖメッセージｊを送信する。ＳＮＭＰ受信部７５はポリシサーバ８０からの設定情報ｈを受け、ＳＮＭＰ送信部７９はポリシサーバ８０に対してネットワーク情報ｍを送信する。
次に、以上の構成を有するネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新される。また、この動的ネットワーク情報テーブル８２は、帯域予約許可判断部９１における許可判断のデータとして用いられる。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、ＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、Ｐａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂをＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１で受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２に記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、そのデータはアドミッション要求部５５に渡される。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１は、あらかじめ与えられた帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とに基づいて帯域予約許可の判断を行う。ここで、動的ネットワーク情報テーブル８２の例を図１４に示す。
図１４は動的ネットワーク情報テーブルの一例を示す図である。動的ネットワーク情報テーブルは、たとえば経路区間と輻輳状態を示す輻輳とのフィールドを有し、各ネットワーク構成装置から通知されたネットワーク情報、この例では、輻輳状態を動的に保存している。図示の例では、クライアント４１を表す装置Ａ−ルータ５０を表す装置Ｂ−ルータ７０を表す装置Ｃ−サーバ４２を表す装置Ｄの経路には輻輳がないことを示し、ネットワーク上の他のルータである装置Ｅ−装置Ｆの経路区間に輻輳が発生していることを示している。
帯域予約許可判断部９１は、アドミッション要求データｆを受けると、帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とを基に帯域予約許可の判断を行う。ここでは、帯域予約判断ポリシテーブル８９が図６に示した帯域予約判断ポリシテーブルとすれば、帯域予約判断ポリシの制限を超えていないことが分かり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルとすれば、クライアント４１とサーバ４２との間の経路区間に輻輳がないことが分かり、これらの判断から帯域予約許可判断部９１は、帯域予約を許可する決定を行うことになる。この帯域予約の許可はＣＯＰＳ送信部９２によりアドミッション結果情報ｇとしてＲＳＶＰ対応のルータ５０へ送信される。また、許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、通知された許可内容とあらかじめ与えられた経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。この場合、経路情報テーブル８３が図７に示した経路情報テーブルとすると、ルータ５０の次はルータ７０であるので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡されて、サービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約情報とからＲＳＶＰ非対応のルータ７０に設定すべき値が決定される。サービスマッピングテーブル８５が図８に示したサービスマッピングテーブルだとすると、装置設定部８７は、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定をする。この設定情報ｈは、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３によりＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊとして送信する。
以上のようにして、第３の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断をポリシサーバ８０に委託する。ポリシサーバ８０は、帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とを基に予約許可の判断をし、その結果をＲＳＶＰ対応のルータ５０に通知するとともに、許可の場合は、許可判断の際に通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。許可判断の結果を受け取ったルータ５０は、許可の場合は、帯域予約を実行するようにした。これにより、ポリシサーバ８０は、帯域予約の許可判断を行うアドミッション制御の際に受け取った情報を基にサービス要求に対応していない経路上のルータ７０を決定してそのルータにサービスを割り当てることができ、しかもサービスの一元管理をすることができる。また、動的なネットワークの状態に応じた許可判断も行うことができる。
次に、第４の実施の形態について説明するが、この第４の実施の形態にて使用される各装置の構成を説明する。ただし、ＲＳＶＰ非対応のルータ７０は第３の実施の形態のものと同じであるので、ここではポリシサーバ８０およびＲＳＶＰ対応のルータ５０のみを示す。
図１５は第４の実施の形態におけるポリシサーバの構成例を示すブロック図、図１６は第４の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図１５に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０から帯域予約情報ｅおよびネットワーク情報ｋを受け、ＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。
ＲＳＶＰ対応のルータ５０は、図１６に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、Ｒｅｓｖメッセージ送信部５６と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３と、帯域予約判断ポリシテーブル６４とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、ＳＮＭＰ送信部６３はポリシサーバ８０に対して帯域予約情報ｅおよびネットワーク情報ｋを送信する。
次に、図１５、図１６および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられる。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新され、その更新内容は経路情報テーブル８３に反映されている。
まず、データ送信者であるサーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をすることができないので、そのままＰａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、帯域予約判断部５８にて帯域予約判断を行う。その際には、予め与えられた帯域予約判断ポリシテーブル６４を用いる。この帯域予約判断ポリシテーブル６４が図６に示した帯域予約判断ポリシテーブルであるとすると、その帯域予約ポリシによれば、ユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約は「５Ｍｂｐｓ」であるので、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていない。したがって、帯域予約判断部５８は帯域予約の許可を行うことになる。
帯域予約の許可の場合には、Ｒｅｓｖメッセージ送信部５６がＲＳＶＰプロトコルのＲｅｓｖメッセージｉにてＲＳＶＰ非対応のルータ７０に送信する。もし、帯域予約が不許可であれば、帯域予約判断部５８は不許可情報ｎをクライアント４１に通知する。ここでは、帯域予約判断部５８は帯域予約の許可を行うので、次に、帯域予約項目設定部６０が帯域予約項目の設定を行う。すなわち、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行う。そして、帯域予約実行部６２は、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。また、帯域予約実行をした後に、その帯域予約情報をＳＮＭＰ送信部６３に通知しておく。ＳＮＭＰ送信部６３は、帯域予約情報ｅをポリシサーバ８０へ通知する。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３にてＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、これを処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２に対してＲＳＶＰプロトコルのＲｅｓｖメッセージｊを送信する。
一方、ポリシサーバ８０は、帯域予約情報ｅをＳＮＭＰ受信部８１にて受け付け、帯域予約の情報を得て、ＲＳＶＰ対応のルータ５０で予約が行われたことを認識する。その帯域予約の情報は、設定装置決定部８４とサービスマッピング部８６とに渡される。設定装置決定部８４は、帯域予約の情報の中に含まれる経路情報と経路情報テーブル８３に設定されているネットワーク情報のデータとからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３を用いるので、元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応できる。ここで、経路情報テーブル８３が図７に示す経路情報テーブルとすれば、この場合、経路上のルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）なので、ＲＳＶＰ非対応のルータ７０が決定される。設定装置決定情報は、サービスマッピング部８６に渡され、サービスマッピング部８６はサービスマッピングテーブル８５とＳＮＭＰ受信部８１から得た帯域予約の情報とからＲＳＶＰ非対応のルータ７０に設定すべき値を決定する。ここで、サービスマッピングテーブル８５が図８に示すサービスマッピングテーブルとすれば、ＳＮＭＰ受信部８１で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、サービスマッピング部８６は、それに対応する優先度割り当ては「３」であることが分かるので、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当て、装置設定部８７がＲＳＶＰ非対応のルータ７０に優先度「３」の割り当てを決定する。この情報は、ＳＮＭＰ送信部８８に渡され、設定情報ｈとしてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
以上のようにして、第４の実施の形態では、ポリシサーバ８０は、経路上の各ルータ５０，７０から得たネットワーク情報を、経路を選択するのに参照される経路情報テーブル８３のデータとして持っており、ポリシサーバ８０がＲＳＶＰ対応のルータから帯域予約をしたという情報を受けたとき、設定装置決定部は経路情報テーブルの一番新しい情報と今まで持っている経路情報とを合わせることでＲＳＶＰ未対応のルータを探し出して、適当なサービスを動的に設定することができるようになる。したがって、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
次に、第５の実施の形態について説明する。この第５の実施の形態にて使用される各装置において、ＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０はそれぞれ第３の実施の形態のものと同じであるので、ここではポリシサーバ８０のみを示す。
図１７は第５の実施の形態におけるポリシサーバの構成例を示すブロック図である。
ポリシサーバ８０は、図１７に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０からそれぞれネットワーク情報ｋ，ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
次に、図１７、図１２および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられる。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新され、その更新内容は経路情報テーブル８３に反映されている。
以上の前提の下で、まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、そのままＰａｔｈメッセージ送信部７２にてＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１にＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ったＲＳＶＰ対応のルータ５０は、そのデータをアドミッション要求部５５に渡す。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１はあらかじめ与えられた帯域予約判断ポリシテーブル８９を基に帯域予約許可の判断を行う。帯域予約判断ポリシテーブル８９が図６に示したテーブルと同じであるとすれば、帯域予約許可判断部９１はこの帯域予約判断ポリシテーブル８９からユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約が「５Ｍｂｐｓ」であることから、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていないため、帯域予約を許可する決定を行う。帯域予約許可判断部９１によるアドミッション結果情報ｇはＣＯＰＳ送信部９２にてＲＳＶＰ対応のルータ５０へ送信される。
また、帯域予約許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、許可内容と経路情報テーブル８３の内容とからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、経路情報テーブル８３は動的ネットワーク情報テーブル８２の内容が反映されているので、元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応することができる。この場合、経路情報テーブル８３が図７の経路情報テーブルであり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルであるとすれば、ルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）であり、しかもこれらの経路には輻輳がないので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡され、そこでサービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とを基にルータ７０に設定するべき値が決定される。図８に示したサービスマッピングテーブルがポリシサーバ８０のサービスマッピングテーブル８５だとすると、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、装置設定部８７は、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定を行う。この設定情報は、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に相当する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
以上のようにして、第５の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断はポリシサーバ８０が帯域予約判断ポリシテーブル８９を基に静的に行い、アドミッション制御の際に受け取った情報と動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３とを基にサービス要求に対応していない経路上のルータ７０を動的に決定してそのルータにサービスを割り当てることができ、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
最後に、第６の実施の形態について説明する。この第６の実施の形態にて使用される各装置において、ＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０はそれぞれ第３の実施の形態のものと同じであるので、ここではポリシサーバ８０のみを示す。
図１８は第６の実施の形態におけるポリシサーバの構成例を示すブロック図である。
ポリシサーバ８０は、図１８に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０からネットワーク情報ｋおよびＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
次に、図１８、図１２および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられ、帯域予約許可判断部９１における許可判断のデータとしても用いられる。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、ＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、Ｐａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂをＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１で受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２に記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、そのデータはアドミッション要求部５５に渡される。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１は、あらかじめ与えられた帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とに基づいて帯域予約許可の判断を行う。ここで、帯域予約判断ポリシテーブル８９が図６で示した帯域予約判断ポリシテーブルと同じであるとすれば、帯域予約判断ポリシの制限を超えていないことが分かり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルと同じであるとすれば、クライアント４１とサーバ４２との間の経路区間に輻輳がないことが分かり、これらの判断から帯域予約許可判断部９１は、帯域予約を許可する決定を行うことになる。この帯域予約の許可はＣＯＰＳ送信部９２によりアドミッション結果情報ｇとしてＲＳＶＰ対応のルータ５０へ送信される。また、許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８５とに通知される。設定装置決定部８４は、通知された許可内容と経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、動的ネットワーク情報テーブルが反映された経路情報テーブルを用いるので元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応することができる。この場合、経路情報テーブル８３が図７に示した経路情報テーブルとすると、ルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）であり、その装置間に輻輳がないので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡されて、サービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とからＲＳＶＰ非対応のルータ７０に設定すべき値が決定される。サービスマッピングテーブル８５が図８に示したサービスマッピングテーブルだとすると、装置設定部８７は、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定をする。この設定情報ｈは、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３によりＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊとして送信する。
以上のようにして、第６の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断はポリシサーバ８０が帯域予約判断ポリシテーブル８９および動的ネットワーク情報テーブル８２を基に動的に行い、アドミッション制御の際に受け取った情報と動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３とを基にサービス要求に対応していない経路上のルータ７０を動的に決定してそのルータにサービスを割り当てることができ、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
また、上記のポリシサーバ８０を構成するコンピュータが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述させておくことができる。このプログラムをコンピュータで実行することにより、上記の各処理がコンピュータで実現できる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリなどがある。市場に流通させる場合には、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフロッピーディスクなどの可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置などにプログラムを格納しておき、メインメモリにロードして実行する。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
本発明はサービス割り当て装置に関し、特にネットワークに存在するさまざまな仕様を持ったネットワーク構成装置の中でサービス要求に対応したサービスを提供することができない装置に対して適当なサービスを割り当てることによりネットワーク全体にて相当のサービス保証を行うことが可能になるサービス割り当て装置に関する。
背景技術
近年、ネットワークにおいては多様なサービスが提供されている。その中に、外部装置からのサービス要求を処理してその要求に応えるというサービスが存在する。しかし、ネットワーク構成装置の中には、ある特定のサービス要求を受け取っても処理を行うことができないために、サービス提供機能を有しているにも拘らず、その特定のサービスを提供できない装置が存在する。しかし、すべてのネットワーク構成装置をそのようなサービス要求に対応したものに切り替えることは現実的ではなく、限りあるネットワーク資源を有効に活用することが望まれている。
ここで、特定のネットワーク構成機器が提供するサービス制御として、帯域保証（ＱｏＳ：Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）制御および優先度（ＣｏＳ：Ｃｌａｓｓ ｏｆ Ｓｅｒｖｉｃｅ）制御が知られている。
帯域保証制御は、たとえばテレビ会議の場合のように、途中で映像データあるいは音声データが途切れたり遅延したりするることがないようエンド・ツー・エンドでサービス品質を動的に保証するものある。この動的に帯域保証制御を行うプロトコルとして、ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ ＲｅＳｅｒＶａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）プロトコルがＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）において標準化されている。これに対し、優先度制御は、あらかじめ設定された優先度に従ってサービスを提供する静的なサービスである。
ここで、このような異なるサービスを提供するネットワーク構成装置がエンド・ツー・エンドで混在する場合の動作について説明する。
図１９は従来のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。ここでは、たとえば、サービス要求者が、帯域を予約するＲＳＶＰプロトコルを用いて通信経路の帯域予約サービスを受けようとした場合を示している。この図において、たとえばクライアント・サーバシステムのサーバとする送信者１０１とクライアントとする受信者１０２とをネットワークによって接続した通信経路上に、ＲＳＶＰプロトコルに対応した対応ルータ１０３、ＲＳＶＰプロトコルに未対応の非対応ルータ１０４、および対応ルータ１０５の三つのネットワーク構成装置が存在しているとする。この例では、通信経路上の対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５で構成されるネットワークが帯域予約を提供することがサービスとなる。
まず、図１９の（Ａ）に示した第１段階では、送信者１０１から受信者１０２に対して経路指定メッセージ（Ｐａｔｈメッセージ）が送信される。経路指定メッセージは、対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５を介して受信者１０２に届く。このとき、対応ルータ１０３，１０５は経路情報を記憶する。
次に、図１９の（Ｂ）に示した第２段階では、受信者１０２は、送信者１０１までの経路に対して帯域予約の要求を行うために帯域予約要求メッセージ（Ｒｅｓｖメッセージ）を送信する。対応ルータ１０５および対応ルータ１０３においては、それぞれ帯域予約要求に対して自己判断を下して帯域予約を実行する。非対応ルータ１０４においては、帯域予約を実行することができないので、帯域予約要求を処理しないで、そのまま帯域予約要求メッセージを次の対応ルータ１０３に転送する。
そして、図１９の（Ｃ）に示した第３段階では、送信者１０１は、受信者１０２に対してデータ送信を行う。ここで、対応ルータ１０３，１０５は帯域予約ができているので帯域予約を提供できているが、非対応ルータ１０４においては帯域予約ができていない。その結果、送信者１０１から受信者１０２までの通信経路において帯域予約は提供できていないことになり、送信者１０１から受信者１０２に対して帯域予約サービスの提供を行うことができない。したがって、送信者１０１からのデータは、部分的に欠落した状態で受信者１０２に届くなどの問題が発生する。
このように、通信経路上にサービス要求を処理できない装置があった場合、その装置では、サービス要求は理解されずに無視されるため、サービスを提供させることはできない。このため、サービス要求に対して、ネットワーク全体にてサービスが提供不可能となることがある。
図２０は従来の別のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。この構成例は、帯域予約要求に対して帯域予約をしていいかどうかの判断をルータ自身が行うのではなく、ネットワークに関連したポリシを管理しているポリシサーバ１０６が行う場合を示している。この例においても、通信経路上の対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５で構成されるネットワークが帯域予約を提供することがサービスとなる。
まず、図２０の（Ａ）に示した第１段階では、送信者１０１から受信者１０２に対して経路指定メッセージが送信され、対応ルータ１０３、非対応ルータ１０４、および対応ルータ１０５を経由して受信者１０２に届く。それぞれＲＳＶＰに対応した対応ルータは経路情報を記憶する。
次に、図２０の（Ｂ）に示した第２段階では、受信者１０２は、送信者１０１までの経路に対して帯域予約の要求を行うために帯域予約要求メッセージを送信する。対応ルータ１０５および対応ルータ１０３においては、それぞれが帯域予約要求を受けると、ポリシサーバ１０６に対して帯域予約許可をＣＯＰＳ（Ｃｏｍｍｏｎ Ｏｐｅｎ Ｐｏｌｉｃｙ Ｓｅｒｖｉｃｅ）プロトコルにて要求を行う。このＣＯＰＳは、ＩＥＴＦのＲＡＰ−ＷＧ（ＲＳＶＰ Ａｄｍｉｓｓｉｏｎ Ｐｏｌｉｃｙ Ｗｏｒｋ Ｇｒｏｕｐ）にて提案された、ＲＳＶＰなどの帯域予約の際に用いられるアドミッション制御（予約の許可・不許可を決定する制御）をポリシに基づいて行うプロトコルである。
ポリシサーバ１０６は持っているポリシから帯域予約許可判断を行って、その判断結果をアドミッション要求を出した対応ルータ１０５，１０３に返す。ここでは、それぞれ予約許可が判断されたものとし、対応ルータ１０５および対応ルータ１０３において帯域予約がなされたものとする。非対応ルータ１０４においては、帯域予約を実行することができないので、帯域予約要求を処理しないで、そのまま帯域予約要求メッセージを次の対応ルータ１０３に転送する。
そして、図２０の（Ｃ）に示した第３段階では、送信者１０１は、受信者１０２に対してデータ送信を行う。ここで、対応ルータ１０３，１０５は帯域予約ができているので帯域予約を提供できているが、非対応ルータ１０４においては帯域予約ができていない。
この結果、ポリシサーバ１０６がネットワークに存在していても、帯域予約許可判断を下すだけであるので、非対応ルータ１０４に対して何か動作を行うものではない。したがって、送信者１０１から受信者１０２に対して帯域予約サービスの提供を行うことができないという問題点があった。
本発明はこのような点に鑑みてなされたものであり、ネットワーク構成装置の中でサービス要求に対応したサービスを提供することができないサービス非対応装置に、適切なサービスを設定することにより、ネットワーク全体でサービスを保証することができるサービス割り当て装置を提供することを目的とする。
発明の開示
すなわち本発明は、ネットワークサービス要求を受け付けて要求されたネットワークサービスを提供することができるサービス要求対応装置からネットワークサービス提供状態情報を知って、外部装置からネットワークサービス設定が可能であって設定されたネットワークサービスを提供することができるサービス要求非対応装置に対してネットワークサービス設定を行うサービス割り当て装置において、前記サービス要求対応装置のネットワークサービス提供状態情報を収集するネットワーク情報収集手段と、前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報を基に前記サービス要求対応装置が提供しているネットワークサービスを提供することができないサービス要求非対応装置を決定する設定装置決定手段と、前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報と前記設定装置決定手段が決定したサービス要求非対応装置の情報とを基に前記サービス要求非対応装置に設定すべきサービスの決定を行うサービスマッピング手段と、前記サービス要求非対応装置に前記サービスマッピング手段で決定されたサービスを設定するサービス設定手段と、を備えていることを特徴とするサービス割り当て装置が提供される。
設定装置決定手段は、ネットワーク情報収集手段がサービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納するとともに設定装置決定手段がサービス要求非対応装置を決定するデータに反映させる動的ネットワーク情報テーブルを有することができる。
このサービス割り当て装置は、さらに、サービス要求対応装置からこのサービス要求対応装置が受け付けたネットワークサービス要求に対してネットワークサービスを提供するかどうかの許可判断の問い合わせを受けて、ネットワークサービス提供の許可判断を下し、判断結果をサービス要求対応装置に通知するとともに許可情報をサービス要求対応装置のネットワークサービス提供状態情報として設定装置決定機能に通知するネットワークサービス提供許可判断手段を備えている。
設定装置決定手段は、また、ネットワーク情報収集手段がサービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納し、設定装置決定手段がサービス要求非対応装置を決定するデータに反映させるとともにネットワーク情報をネットワークサービス提供の許可判断用のデータとする動的ネットワーク情報テーブルを有することができる。
本発明の上記および他の目的、特徴および利点は本発明の例として好ましい実施の形態を表す添付の図面と関連した以下の説明により明らかになるであろう。
【図面の簡単な説明】
図１は本発明によるサービス割り当て装置の原理的構成を示すブロック図である。
図２はネットワーク構成装置の配置図である。
図３は第１の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図４は第１の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図５は第１の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
図６は帯域予約判断ポリシテーブルの一例を示す図である。
図７は経路情報テーブルの一例を示す図である。
図８はサービスマッピングテーブルの一例を示す図である。
図９は第２の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１０は第２の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１１は第３の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１２は第３の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１３は第２の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
図１４は動的ネットワーク情報テーブルの一例を示す図である。
図１５は第４の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１６は第４の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
図１７は第５の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１８は第６の実施の形態におけるポリシサーバの構成例を示すブロック図である。
図１９は従来のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。
図２０は従来の別のネットワーク構成装置の動作を説明する図であって、（Ａ）は第１段階の説明を示し、（Ｂ）は第２段階の説明を示し、（Ｃ）は第３段階の説明を示している。
発明を実施するための最良の形態
まず、本発明の概略について図面を参照して説明する。
図１は本発明によるサービス割り当て装置の原理的構成を示すブロック図である。サービス割り当て装置１０は、ネットワーク構成装置であるサービス要求対応装置２０およびサービス要求非対応装置３０に接続されている。サービス割り当て装置１０は、ネットワーク情報収集手段１１と、設定装置決定手段１２と、サービスマッピング手段１３と、サービス設定手段１４とを備えている。
ここで、サービス要求対応装置２０は、ネットワークサービス要求を受け付け、受け付けたネットワークサービスを提供する機能、およびサービス割り当て装置１０にサービス提供状態情報を与える機能を有している。また、サービス要求非対応装置３０は、ネットワークサービス要求を受け付けるが、その要求に対する処理は行わない。しかし、サービス要求非対応装置３０は、外部装置からサービス設定要求を受け付け、設定を行う機能、および設定されたサービスを提供する機能を有している。
サービス割り当て装置１０において、ネットワーク情報収集手段１１は、サービス要求対応装置２０からサービス提供状態情報を収集する機能を有し、設定装置決定手段１２は、ネットワーク情報収集手段１１が収集したサービス提供状態情報からサービス設定すべきサービス要求非対応装置を決定する機能を有し、サービスマッピング手段１３は、ネットワーク情報収集手段１１が収集したサービス提供状態情報および設定装置決定手段１２が決定したサービス要求非対応装置のデータを用いてサービスマッピング、すなわちサービス設定項目の決定および設定値の変換を行うネットワーク情報・サービス設定連携機能を有し、サービス設定手段１４は、サービスマッピング手段１３から通知されたサービス設定情報を設定装置決定手段１２によって決定されたサービス要求非対応装置３０に対して設定を行う機能を有している。
以上の構成において、まず、サービス要求対応装置２０は、ネットワークサービス要求を受けて、その要求に対する処理をして、サービスを提供する。そのサービス提供状態情報は、サービス割り当て装置１０のネットワーク情報収集手段１１により収集され、さらに設定装置決定手段１２およびサービスマッピング手段１３へ通知される。
設定装置決定手段１２は、ネットワーク情報収集手段１１から受け取ったサービス提供状態情報を基に、ネットワークサービス要求を処理することができないサービス要求非対応装置３０を決定し、決定内容をサービスマッピング手段１３へ通知する。サービスマッピング手段１３は、ネットワーク情報収集手段１１から受け取ったサービス提供状態情報と設定装置決定手段１２から受け取った決定内容とを基にして、サービス要求非対応装置３０に設定すべきサービスを決定し、そのデータをサービス設定手段１４に通知する。そして、サービス設定手段１４は、サービスマッピング手段１３から受け取ったデータをサービス要求非対応装置３０に設定する。
これにより、ネットワークサービス要求に対して処理ができないためにサービスを提供することができないサービス要求非対応装置３０に対して、サービス要求対応装置２０と同じ、あるいは対応したサービスの提供を行わせることができる。すなわち、サービス要求非対応装置３０が有する固有のサービスを割り当てることができ、サービス要求非対応装置３０においてもサービス提供が可能となる。
また、サービス割り当て装置１０は、サービス要求対応装置２０がネットワークサービス要求を受けたときに、要求されたサービスを提供するかどうかの許可の決定を行うサービス提供許可判断手段を備えている。
これにより、サービス要求対応装置２０は、ネットワークサービス要求を受けると、サービス割り当て装置１０に対して、サービス提供の許可不許可の決定の委託を行う。サービス割り当て装置１０では、サービス提供許可判断手段がサービス要求対応装置２０からのサービス提供の許可不許可の決定要求を受け付け、受け付けたサービス提供の許可不許可の決定要求に対して、記憶している判断データから決定を下す。サービス提供許可判断手段は、そのサービス提供の許可不許可の決定をサービス要求対応装置２０に与えると、サービス要求対応装置２０は、許可不許可決定の結果を受けて、サービス提供をするしないを実行する。
設定装置決定手段１２は、サービス提供許可判断手段が受け付けたサービス提供の許可不許可の決定要求からサービス提供情報を知り、サービス設定すべきサービス要求非対応装置３０を決定し、決定内容をサービスマッピング手段１３へ通知する。サービスマッピング手段１３は、サービス提供許可判断手段から受け取ったサービス提供状態情報と設定装置決定手段１２から受け取った決定内容とを基にして、サービス要求非対応装置３０に設定すべきサービスを決定し、そのデータをサービス設定手段１４に通知する。そして、サービス設定手段１４は、サービスマッピング手段１３から受け取ったデータをサービス要求非対応装置３０に設定する。
このように、サービス割り当て装置１０は、サービス提供許可判断手段を備えたことにより、サービス要求対応装置２０からのサービス提供の許可不許可の決定要求に対応する事ができる。
さらに、サービス割り当て装置１０のネットワーク情報収集手段１１は、サービス要求対応装置２０およびサービス要求非対応装置３０からそれらの設定や装置の状態を知ることができるネットワーク状態監視手段を備えている。
これにより、サービス割り当て装置１０では、サービス提供許可判断手段は、受け付けたサービス提供の許可不許可の決定要求に対して、ネットワーク状態監視手段が知ったネットワーク状態から決定を下す。
これにより、ネットワーク状態がサービスを提供できない状態であってもサービス提供許可判断手段はサービス提供の許可不許可の決定要求に対応して許可を出す可能性があったが、許可不許可の判断材料にネットワーク状態の情報を用いることにより、サービス要求対応装置２０に対して、ネットワーク状態を考慮して、適切なサービス提供の許可不許可の決定を通知することができる。
さらに、設定装置決定手段１２は、ネットワーク情報収集手段１１で集めた各ネットワークの状態情報を受け取ってサービス要求非対応装置３０を決定するようにすることができる。これにより、ネットワーク状態によってサービス要求非対応装置３０の位置が動的に変化する場合には、設定装置決定手段１２はサービス要求非対応装置３０の決定にネットワーク状態の情報を用いることが可能なため、ネットワーク状態によるサービス要求非対応装置３０の位置変化にも対応して、サービス要求非対応装置３０の位置決定をすることができる。
次に、本発明の実施の形態を、ポリシサーバに適用した場合を例にして説明する。サービスは、通信の品質に関する帯域予約サービス、セキュリティに関するアクセス認証サービス、プログラムやデータの転送に関する資源配布サービスなど様々であるが、以下では、サービス要求者がＲＳＶＰプロトコルを用いてエンド・ツー・エンド通信に対して帯域予約を求め、ネットワークが要求された通信に対して帯域を予約する帯域予約サービスを例に挙げる。
図２はネットワーク構成装置の配置図である。図２において、クライアント４１およびサーバ４２は、たとえば二つのルータ５０，７０によって構成されるデータ伝達媒体であるネットワークによって接続されており、通信経路上のこれら二つのルータ５０，７０には、ポリシサーバ８０が接続されている。ここで、クライアント４１はサービス要求者であり、サーバ４２はデータ送信者である。また、ルータ５０はＲＳＶＰ資源予約要求を受け付けて資源予約を提供することができるＲＳＶＰ対応のルータであり、ルータ７０はＲＳＶＰ資源予約要求を受け付け処理することができないが、外部から設定された制御情報に従ってサービス提供を行うことができるＲＳＶＰ非対応のルータである。ポリシサーバ８０はルータ５０の帯域予約情報を基にＲＳＶＰ非対応のルータ７０に適切な設定情報を割り当てるサービス割り当て装置として機能する。なお、説明を簡単にするため、クライアント４１を装置Ａ、ルータ５０を装置Ｂ、ルータ７０を装置Ｃ、サーバ４２を装置Ｄと表記することもある。また、各装置間の信号の詳細については、以下の各実施の形態にて説明する。
まず、第１の実施の形態について説明するが、この第１の実施の形態にて使用される各装置の構成を説明する。
図３は第１の実施の形態におけるポリシサーバの構成例を示すブロック図、図４は第１の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図、図５は第１の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図３に示したように、ＳＮＭＰ受信部８１と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０から帯域予約情報ｅを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。
ＲＳＶＰ対応のルータ５０は、図４に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、Ｒｅｓｖメッセージ送信部５６と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３と、帯域予約判断ポリシテーブル６４とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、許可と判断した場合にＳＮＭＰ送信部６３はポリシサーバ８０に対して帯域予約情報ｅを送信する。
ＲＳＶＰ非対応のルータ７０は、図５に示したように、Ｐａｔｈメッセージ受信部７１と、Ｐａｔｈメッセージ送信部７２と、Ｒｅｓｖメッセージ受信部７３と、Ｒｅｓｖメッセージ送信部７４と、ＳＮＭＰ受信部７５と、帯域予約項目設定部７６と、サービスマッピング部７７と、帯域予約実行部７８とから構成されている。Ｐａｔｈメッセージ受信部７１はサーバ４２からのＰａｔｈメッセージａを受け、Ｐａｔｈメッセージ送信部７２はＲＳＶＰ対応のルータ５０に対してＰａｔｈメッセージｂを送信し、Ｒｅｓｖメッセージ受信部７３はＲＳＶＰ対応のルータ５０からのＲｅｓｖメッセージｉを受け、Ｒｅｓｖメッセージ送信部７４はサーバ４２に対してＲｅｓｖメッセージｊを送信し、ＳＮＭＰ受信部７５はポリシサーバ８０からの設定情報ｈを受ける。
次に、以上の構成を有するネットワーク構成装置の動作について説明する。
まず、データ送信者であるサーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をすることができないので、そのままＰａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、帯域予約判断部５８にて帯域予約判断を行う。その際には、帯域予約判断ポリシテーブル６４が用いられる。この帯域予約判断ポリシテーブル６４の例を図６に示す。
図６は帯域予約判断ポリシテーブルの一例を示す図である。この帯域予約判断テーブルは、少なくともユーザ名および最大帯域予約量のフィールドを持ち、各ユーザが予約することができる最大帯域量を定義している。この帯域予約判断テーブルは、帯域予約判断部５８が要求された帯域を予約していいかどうかの許可判断を行うときの判断材料として参照される。
さて、帯域予約判断部５８では、Ｒｅｓｖメッセージ受信部５４からのＲｅｓｖメッセージｄと帯域予約判断ポリシテーブル６４とから帯域予約判断を行う。すなわち、帯域予約判断ポリシテーブル６４の帯域予約ポリシによると、ユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約は「５Ｍｂｐｓ」なので、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていない。したがって、帯域予約判断部５８は帯域予約の許可を行うことになる。
帯域予約の許可の場合には、Ｒｅｓｖメッセージ送信部５６がＲＳＶＰプロトコルのＲｅｓｖメッセージｉにてＲＳＶＰ非対応のルータ７０に送信する。もし、帯域予約が不許可であれば、帯域予約判断部５８は不許可情報ｎをクライアント４１に通知する。ここでは、帯域予約判断部５８は帯域予約の許可を行うので、次に、帯域予約項目設定部６０が帯域予約項目の設定を行う。すなわち、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行う。そして、帯域予約実行部６２は、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。また、帯域予約実行をした後に、その帯域予約情報をＳＮＭＰ送信部６３に通知しておく。ＳＮＭＰ送信部６３は、帯域予約情報ｅをポリシサーバ８０へ通知する。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３にてＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、これを処理できないので、そのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊを送信する。
一方、ポリシサーバ８０は、帯域予約情報ｅをＳＮＭＰ受信部８１にて受け付け、帯域予約の情報を得て、ＲＳＶＰ対応のルータ５０で予約が行われたことを認識する。その帯域予約の情報は、設定装置決定部８４とサービスマッピング部８６とに渡される。設定装置決定部８４は、帯域予約の情報の中に含まれる経路情報と経路情報テーブル８３に設定されているネットワーク情報のデータとからＲＳＶＰ非対応のルータ７０の位置を決定する。ここで、経路情報テーブル８３の例を図７に示す。
図７は経路情報テーブルの一例を示す図である。この経路情報テーブルは、装置名と経路上の次の装置とのフィールドを有し、ネットワーク上のあるネットワーク構成装置に対して経路上の次のネットワーク構成装置があらかじめ定義されている。装置名としては、ネットワーク上の位置情報であるたとえばＩＰ（ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）アドレスが使用される。
設定装置決定部８４は、帯域予約の情報と経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。この場合、図７のあらかじめ与えられた経路情報テーブル８３を見ると、ルータ５０の次はルータ７０なので、ＲＳＶＰ非対応のルータ７０が決定される。設定装置決定情報は、サービスマッピング部８６に渡され、サービスマッピング部８６は設定装置決定情報とＳＮＭＰ受信部８１から得た帯域予約の情報とを基にして、サービスマッピングテーブル８５からＲＳＶＰ非対応のルータ７０に設定すべき値を決定する。ここで、サービスマッピングテーブル８５の例を図８に示す。
図８はサービスマッピングテーブルの一例を示す図である。サービスマッピングテーブルは、ユーザ名、帯域予約量、および優先度割り当てのフィールドを持ち、各ユーザが要求した帯域予約サービスに対して妥当であると思われる優先度のサービスを定義した変換テーブルである。
サービスマッピング部８６は、ＳＮＭＰ受信部８１で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、サービスマッピングテーブル８５を参照すると、それに対応する優先度割り当ては「３」であることが分かるので、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当て、装置設定部８７がＲＳＶＰ非対応のルータ７０に優先度「３」の割り当てを決定する。この情設は、ＳＮＭＰ送信部８８に渡され、設定情報ｈとしてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
以上のようにして、第１の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかを帯域予約判断ポリシテーブル６４に基づき自身で判断して帯域予約を実行し、その帯域予約情報をポリシサーバに通知する。ポリシサーバ８０では、通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。これにより、ＲＳＶＰ未対応のルータにも相当のサービスを動的に設定することができるようになる。したがって、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在したネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
次に、第２の実施の形態について説明するが、この第２の実施の形態にて使用される各装置の構成を説明する。ただし、ＲＳＶＰ非対応のルータ７０は第１の実施の形態のものと同じであるので、ポリシサーバ８０およびＲＳＶＰ対応のルータ５０のみを示す。
図９は第２の実施の形態におけるポリシサーバの構成例を示すブロック図、図１０は第２の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図９に示したように、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信し、ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
ＲＳＶＰ対応のルータ５０は、図１０に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、アドミッション要求部５５と、Ｒｅｓｖメッセージ送信部５６と、ＣＯＰＳ受信部５７と、帯域予約判断部５８と、ＣＯＰＳ送信部５９と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、ＣＯＰＳ受信部５７はポリシサーバ８０からのアドミッション結果情報ｇを受け、ＣＯＰＳ送信部５９はポリシサーバ８０に対してアドミッション要求データｆを送信する。
次に、図９、図１０および図５に示したネットワーク構成装置の動作について説明する。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、そのままＰａｔｈメッセージ送信部７２にてＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１にＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ったＲＳＶＰ対応のルータ５０は、そのデータをアドミッション要求部５５に渡す。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１はあらかじめ与えられた帯域予約判断ポリシテーブル８９を基に帯域予約許可の判断を行う。帯域予約判断ポリシテーブル８９が図６に示したテーブルと同じであるとすれば、帯域予約許可判断部９１はこの帯域予約判断ポリシテーブル８９からユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約が「５Ｍｂｐｓ」であることから、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていないため、帯域予約を許可する決定を行う。帯域予約許可判断部９１によるアドミッション結果情報ｇはＣＯＰＳ送信部９２にてＲＳＶＰ対応のルータ５０へ送信される。
また、帯域予約許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、許可内容とあらかじめ与えられた経路情報テーブル８３の内容とからＲＳＶＰ非対応のルータ７０の位置を決定する。ここで、あらかじめ与えられた経路情報テーブル８３が図７の経路情報テーブルであるとすれば、ルータ５０の次はルータ７０であるので、ＲＳＶＰ非対応のルータ７０が決定される。ルータ７０の決定情報は、サービスマッピング部８６に渡され、そこでサービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とを基にルータ７０に設定するべき値が決定される。図８に示したサービスマッピングテーブルがポリシサーバ８０のサービスマッピングテーブル８５だとすると、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、装置設定部８７は、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定を行う。この設定情報は、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
以上のようにして、第２の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断をポリシサーバ８０に委託する。ポリシサーバ８０は、帯域予約判断ポリシテーブル８９を基に予約許可の判断をし、その結果をＲＳＶＰ対応のルータ５０に通知するとともに、許可の場合は、許可判断の際に通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。許可判断の結果を受け取ったルータ５０は、許可の場合は、帯域予約を実行するようにした。これにより、ポリシサーバ８０は、帯域予約の許可判断を行うアドミッション制御の際に受け取った情報を基にサービス要求に対応していない経路上のルータ７０を決定してそのルータにサービスを割り当てることができ、しかもサービスの一元管理をすることができる。
次に、第３の実施の形態について説明するが、この第３の実施の形態にて使用される各装置の構成を説明する。
図１１は第３の実施の形態におけるポリシサーバの構成例を示すブロック図、図１２は第３の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図、図１３は第２の実施の形態におけるＲＳＶＰ非対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図１１に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０からネットワーク情報ｋおよびＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信し、ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
ＲＳＶＰ対応のルータ５０は、図１２に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、アドミッション要求部５５と、Ｒｅｓｖメッセージ送信部５６と、ＣＯＰＳ受信部５７と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信する。そして、ＣＯＰＳ受信部５７はポリシサーバ８０からのアドミッション結果情報ｇを受け、ＣＯＰＳ送信部５９はポリシサーバ８０に対してアドミッション要求データｆを送信し、ＳＮＭＰ送信部６３はポリシサーバ８０に対してネットワーク情報ｋを送信する。
ＲＳＶＰ非対応のルータ７０は、図１３に示したように、Ｐａｔｈメッセージ受信部７１と、Ｐａｔｈメッセージ送信部７２と、Ｒｅｓｖメッセージ受信部７３と、Ｒｅｓｖメッセージ送信部７４と、ＳＮＭＰ受信部７５と、帯域予約項目設定部７６と、サービスマッピング部７７と、帯域予約実行部７８と、ＳＮＭＰ送信部７９とから構成されている。Ｐａｔｈメッセージ受信部７１はサーバ４２からのＰａｔｈメッセージａを受け、Ｐａｔｈメッセージ送信部７２はＲＳＶＰ対応のルータ５０に対してＰａｔｈメッセージｂを送信する。Ｒｅｓｖメッセージ受信部７３はＲＳＶＰ対応のルータ５０からのＲｅｓｖメッセージｉを受け、Ｒｅｓｖメッセージ送信部７４はサーバ４２に対してＲｅｓｖメッセージｊを送信する。ＳＮＭＰ受信部７５はポリシサーバ８０からの設定情報ｈを受け、ＳＮＭＰ送信部７９はポリシサーバ８０に対してネットワーク情報ｍを送信する。
次に、以上の構成を有するネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新される。また、この動的ネットワーク情報テーブル８２は、帯域予約許可判断部９１における許可判断のデータとして用いられる。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、ＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、Ｐａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂをＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１で受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２に記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、そのデータはアドミッション要求部５５に渡される。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１は、あらかじめ与えられた帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とに基づいて帯域予約許可の判断を行う。ここで、動的ネットワーク情報テーブル８２の例を図１４に示す。
図１４は動的ネットワーク情報テーブルの一例を示す図である。動的ネットワーク情報テーブルは、たとえば経路区間と輻輳状態を示す輻輳とのフィールドを有し、各ネットワーク構成装置から通知されたネットワーク情報、この例では、輻輳状態を動的に保存している。図示の例では、クライアント４１を表す装置Ａ−ルータ５０を表す装置Ｂ−ルータ７０を表す装置Ｃ−サーバ４２を表す装置Ｄの経路には輻輳がないことを示し、ネットワーク上の他のルータである装置Ｅ−装置Ｆの経路区間に輻輳が発生していることを示している。
帯域予約許可判断部９１は、アドミッション要求データｆを受けると、帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とを基に帯域予約許可の判断を行う。ここでは、帯域予約判断ポリシテーブル８９が図６に示した帯域予約判断ポリシテーブルとすれば、帯域予約判断ポリシの制限を超えていないことが分かり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルとすれば、クライアント４１とサーバ４２との間の経路区間に輻輳がないことが分かり、これらの判断から帯域予約許可判断部９１は、帯域予約を許可する決定を行うことになる。この帯域予約の許可はＣＯＰＳ送信部９２によりアドミッション結果情報ｇとしてＲＳＶＰ対応のルータ５０へ送信される。また、許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、通知された許可内容とあらかじめ与えられた経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。この場合、経路情報テーブル８３が図７に示した経路情報テーブルとすると、ルータ５０の次はルータ７０であるので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡されて、サービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約情報とからＲＳＶＰ非対応のルータ７０に設定すべき値が決定される。サービスマッピングテーブル８５が図８に示したサービスマッピングテーブルだとすると、装置設定部８７は、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定をする。この設定情報ｈは、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３によりＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊとして送信する。
以上のようにして、第３の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断をポリシサーバ８０に委託する。ポリシサーバ８０は、帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とを基に予約許可の判断をし、その結果をＲＳＶＰ対応のルータ５０に通知するとともに、許可の場合は、許可判断の際に通知された帯域予約情報とあらかじめ設定された経路情報テーブルとからサービス要求に対応していない経路上のルータ７０を静的に決定し、そのルータに対して、ルータ５０の帯域予約サービスに相当するサービスの設定を行う。許可判断の結果を受け取ったルータ５０は、許可の場合は、帯域予約を実行するようにした。これにより、ポリシサーバ８０は、帯域予約の許可判断を行うアドミッション制御の際に受け取った情報を基にサービス要求に対応していない経路上のルータ７０を決定してそのルータにサービスを割り当てることができ、しかもサービスの一元管理をすることができる。また、動的なネットワークの状態に応じた許可判断も行うことができる。
次に、第４の実施の形態について説明するが、この第４の実施の形態にて使用される各装置の構成を説明する。ただし、ＲＳＶＰ非対応のルータ７０は第３の実施の形態のものと同じであるので、ここではポリシサーバ８０およびＲＳＶＰ対応のルータ５０のみを示す。
図１５は第４の実施の形態におけるポリシサーバの構成例を示すブロック図、図１６は第４の実施の形態におけるＲＳＶＰ対応のルータの構成例を示すブロック図である。
ポリシサーバ８０は、図１５に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０から帯域予約情報ｅおよびネットワーク情報ｋを受け、ＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。
ＲＳＶＰ対応のルータ５０は、図１６に示したように、Ｐａｔｈメッセージ受信部５１と、経路記憶部５２と、Ｐａｔｈメッセージ送信部５３と、Ｒｅｓｖメッセージ受信部５４と、Ｒｅｓｖメッセージ送信部５６と、帯域予約判断部５８と、帯域予約項目設定部６０と、サービスマッピング部６１と、帯域予約実行部６２と、ＳＮＭＰ送信部６３と、帯域予約判断ポリシテーブル６４とから構成されている。Ｐａｔｈメッセージ受信部５１はＲＳＶＰ非対応のルータ７０からのＰａｔｈメッセージｂを受け、Ｐａｔｈメッセージ送信部５３はクライアント４１に対してＰａｔｈメッセージｃを送信し、Ｒｅｓｖメッセージ受信部５４はクライアント４１からのＲｅｓｖメッセージｄを受け、Ｒｅｓｖメッセージ送信部５６はＲＳＶＰ非対応のルータ７０に対してＲｅｓｖメッセージｉを送信する。帯域予約判断部５８は帯域予約が不許可と判断した場合にクライアント４１に対して不許可情報ｎを送信し、ＳＮＭＰ送信部６３はポリシサーバ８０に対して帯域予約情報ｅおよびネットワーク情報ｋを送信する。
次に、図１５、図１６および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられる。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新され、その更新内容は経路情報テーブル８３に反映されている。
まず、データ送信者であるサーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をすることができないので、そのままＰａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、帯域予約判断部５８にて帯域予約判断を行う。その際には、予め与えられた帯域予約判断ポリシテーブル６４を用いる。この帯域予約判断ポリシテーブル６４が図６に示した帯域予約判断ポリシテーブルであるとすると、その帯域予約ポリシによれば、ユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約は「５Ｍｂｐｓ」であるので、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていない。したがって、帯域予約判断部５８は帯域予約の許可を行うことになる。
帯域予約の許可の場合には、Ｒｅｓｖメッセージ送信部５６がＲＳＶＰプロトコルのＲｅｓｖメッセージｉにてＲＳＶＰ非対応のルータ７０に送信する。もし、帯域予約が不許可であれば、帯域予約判断部５８は不許可情報ｎをクライアント４１に通知する。ここでは、帯域予約判断部５８は帯域予約の許可を行うので、次に、帯域予約項目設定部６０が帯域予約項目の設定を行う。すなわち、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行う。そして、帯域予約実行部６２は、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。また、帯域予約実行をした後に、その帯域予約情報をＳＮＭＰ送信部６３に通知しておく。ＳＮＭＰ送信部６３は、帯域予約情報ｅをポリシサーバ８０へ通知する。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３にてＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、これを処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２に対してＲＳＶＰプロトコルのＲｅｓｖメッセージｊを送信する。
一方、ポリシサーバ８０は、帯域予約情報ｅをＳＮＭＰ受信部８１にて受け付け、帯域予約の情報を得て、ＲＳＶＰ対応のルータ５０で予約が行われたことを認識する。その帯域予約の情報は、設定装置決定部８４とサービスマッピング部８６とに渡される。設定装置決定部８４は、帯域予約の情報の中に含まれる経路情報と経路情報テーブル８３に設定されているネットワーク情報のデータとからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３を用いるので、元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応できる。ここで、経路情報テーブル８３が図７に示す経路情報テーブルとすれば、この場合、経路上のルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）なので、ＲＳＶＰ非対応のルータ７０が決定される。設定装置決定情報は、サービスマッピング部８６に渡され、サービスマッピング部８６はサービスマッピングテーブル８５とＳＮＭＰ受信部８１から得た帯域予約の情報とからＲＳＶＰ非対応のルータ７０に設定すべき値を決定する。ここで、サービスマッピングテーブル８５が図８に示すサービスマッピングテーブルとすれば、ＳＮＭＰ受信部８１で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、サービスマッピング部８６は、それに対応する優先度割り当ては「３」であることが分かるので、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当て、装置設定部８７がＲＳＶＰ非対応のルータ７０に優先度「３」の割り当てを決定する。この情報は、ＳＮＭＰ送信部８８に渡され、設定情報ｈとしてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
以上のようにして、第４の実施の形態では、ポリシサーバ８０は、経路上の各ルータ５０，７０から得たネットワーク情報を、経路を選択するのに参照される経路情報テーブル８３のデータとして持っており、ポリシサーバ８０がＲＳＶＰ対応のルータから帯域予約をしたという情報を受けたとき、設定装置決定部は経路情報テーブルの一番新しい情報と今まで持っている経路情報とを合わせることでＲＳＶＰ未対応のルータを探し出して、適当なサービスを動的に設定することができるようになる。したがって、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
次に、第５の実施の形態について説明する。この第５の実施の形態にて使用される各装置において、ＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０はそれぞれ第３の実施の形態のものと同じであるので、ここではポリシサーバ８０のみを示す。
図１７は第５の実施の形態におけるポリシサーバの構成例を示すブロック図である。
ポリシサーバ８０は、図１７に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０からそれぞれネットワーク情報ｋ，ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
次に、図１７、図１２および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられる。したがって、動的ネットワーク情報テーブル８２の内容は現在のネットワーク状況に応じて動的に更新され、その更新内容は経路情報テーブル８３に反映されている。
以上の前提の下で、まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、Ｐａｔｈメッセージ受信部７１で受けたＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、そのままＰａｔｈメッセージ送信部７２にてＲＳＶＰプロトコルのＰａｔｈメッセージｂとしてＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１が受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２にて記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１にＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ったＲＳＶＰ対応のルータ５０は、そのデータをアドミッション要求部５５に渡す。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１はあらかじめ与えられた帯域予約判断ポリシテーブル８９を基に帯域予約許可の判断を行う。帯域予約判断ポリシテーブル８９が図６に示したテーブルと同じであるとすれば、帯域予約許可判断部９１はこの帯域予約判断ポリシテーブル８９からユーザ名「Ｋｕｒｏｓｅ」の最大帯域予約が「５Ｍｂｐｓ」であることから、ＲＳＶＰプロトコルのＲｅｓｖメッセージ中の帯域予約パラメータは制限を越えていないため、帯域予約を許可する決定を行う。帯域予約許可判断部９１によるアドミッション結果情報ｇはＣＯＰＳ送信部９２にてＲＳＶＰ対応のルータ５０へ送信される。
また、帯域予約許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８６とに通知される。設定装置決定部８４は、許可内容と経路情報テーブル８３の内容とからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、経路情報テーブル８３は動的ネットワーク情報テーブル８２の内容が反映されているので、元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応することができる。この場合、経路情報テーブル８３が図７の経路情報テーブルであり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルであるとすれば、ルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）であり、しかもこれらの経路には輻輳がないので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡され、そこでサービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とを基にルータ７０に設定するべき値が決定される。図８に示したサービスマッピングテーブルがポリシサーバ８０のサービスマッピングテーブル８５だとすると、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、装置設定部８７は、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定を行う。この設定情報は、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に相当する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング部６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
以上のようにして、第５の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断はポリシサーバ８０が帯域予約判断ポリシテーブル８９を基に静的に行い、アドミッション制御の際に受け取った情報と動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３とを基にサービス要求に対応していない経路上のルータ７０を動的に決定してそのルータにサービスを割り当てることができ、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
最後に、第６の実施の形態について説明する。この第６の実施の形態にて使用される各装置において、ＲＳＶＰ対応のルータ５０およびＲＳＶＰ非対応のルータ７０はそれぞれ第３の実施の形態のものと同じであるので、ここではポリシサーバ８０のみを示す。
図１８は第６の実施の形態におけるポリシサーバの構成例を示すブロック図である。
ポリシサーバ８０は、図１８に示したように、ＳＮＭＰ受信部８１と、動的ネットワーク情報テーブル８２と、経路情報テーブル８３と、設定装置決定部８４と、サービスマッピングテーブル８５と、サービスマッピング部８６と、装置設定部８７と、ＳＮＭＰ送信部８８と、帯域予約判断ポリシテーブル８９と、ＣＯＰＳ受信部９０と、帯域予約許可判断部９１と、ＣＯＰＳ送信部９２とから構成されている。ＳＮＭＰ受信部８１はＲＳＶＰ対応のルータ５０からネットワーク情報ｋおよびＲＳＶＰ非対応のルータ７０からネットワーク情報ｍを受け、ＳＮＭＰ送信部８８はＲＳＶＰ非対応のルータ７０に対して設定情報ｈを送信する。ＣＯＰＳ受信部９０はＲＳＶＰ対応のルータ５０からのアドミッション要求データｆを受け、ＣＯＰＳ送信部９２はＲＳＶＰ対応のルータ５０に対してアドミッション結果情報ｇを送信する。
次に、図１８、図１２および図１３に示したネットワーク構成装置の動作について説明する。
前提の動作として、ＲＳＶＰ対応のルータ５０は、自身の設定内容や負荷状態などのネットワーク情報ｋをＳＮＭＰ送信部６３を用いて定期的にポリシサーバ８０へ送信する。ＲＳＶＰ非対応のルータ７０も、自身の設定内容や負荷状態などのネットワーク情報ｍをＳＮＭＰ送信部７９を用いて定期的にポリシサーバ８０へ送信する。ポリシサーバ８０は、それらのネットワーク情報ｋ，ｍをＳＮＭＰ受信部８１で受け、その内容を動的ネットワーク情報テーブル８２に格納しておく。また、動的ネットワーク情報テーブル８２は、経路情報テーブル８３のデータとして用いられ、帯域予約許可判断部９１における許可判断のデータとしても用いられる。
まず、サーバ４２からＲＳＶＰプロトコルのＰａｔｈメッセージａがＲＳＶＰ非対応のルータ７０に対して送信される。ＲＳＶＰ非対応のルータ７０は、ＲＳＶＰプロトコルのＰａｔｈメッセージａに対して処理をせずに、Ｐａｔｈメッセージ送信部７２によりＲＳＶＰプロトコルのＰａｔｈメッセージｂをＲＳＶＰ対応のルータ５０へ送信する。
ＲＳＶＰ対応のルータ５０は、Ｐａｔｈメッセージ受信部５１で受信したＲＳＶＰプロトコルのＰａｔｈメッセージｂからＲＳＶＰプロトコルのＰａｔｈメッセージが経由してきた装置の経路を経路記憶部５２に記憶した後、Ｐａｔｈメッセージ送信部５３によりクライアント４１に対してＲＳＶＰプロトコルのＰａｔｈメッセージｃを送信する。
クライアント４１は、帯域予約サービスを受けるために、ＲＳＶＰプロトコルのＲｅｓｖメッセージｄをＲＳＶＰ対応のルータ５０に送信する。ここで、帯域予約要求の例として、ユーザ名「Ｋｕｒｏｓｅ」で、帯域は「５Ｍｂｐｓ」とする。
ＲＳＶＰ対応のルータ５０は、Ｒｅｓｖメッセージ受信部５４にてＲＳＶＰプロトコルのＲｅｓｖメッセージｄを受け取ると、そのデータはアドミッション要求部５５に渡される。アドミッション要求部５５は、帯域予約の許可・不許可を要求するアドミッション要求データｆをＣＯＰＳ送信部５９に渡して、ポリシサーバ８０に送信する。
ポリシサーバ８０は、アドミッション要求データｆをＣＯＰＳ受信部９０で受けて、帯域予約許可判断部９１に通知する。帯域予約許可判断部９１は、あらかじめ与えられた帯域予約判断ポリシテーブル８９と動的ネットワーク情報テーブル８２とに基づいて帯域予約許可の判断を行う。ここで、帯域予約判断ポリシテーブル８９が図６で示した帯域予約判断ポリシテーブルと同じであるとすれば、帯域予約判断ポリシの制限を超えていないことが分かり、動的ネットワーク情報テーブル８２が図１４に示した動的ネットワーク情報テーブルと同じであるとすれば、クライアント４１とサーバ４２との間の経路区間に輻輳がないことが分かり、これらの判断から帯域予約許可判断部９１は、帯域予約を許可する決定を行うことになる。この帯域予約の許可はＣＯＰＳ送信部９２によりアドミッション結果情報ｇとしてＲＳＶＰ対応のルータ５０へ送信される。また、許可の場合は、許可内容が設定装置決定部８４とサービスマッピング部８５とに通知される。設定装置決定部８４は、通知された許可内容と経路情報テーブル８３とからＲＳＶＰ非対応のルータ７０の位置を決定する。このとき、動的ネットワーク情報テーブルが反映された経路情報テーブルを用いるので元々持っている経路情報テーブルが現在の経路情報テーブルにそぐわないといった動的なネットワーク経路変更などや装置の故障などに対応することができる。この場合、経路情報テーブル８３が図７に示した経路情報テーブルとすると、ルータ５０（装置Ｂ）の次はルータ７０（装置Ｃ）であり、その装置間に輻輳がないので、ＲＳＶＰ非対応のルータ７０が決定される。ＲＳＶＰ非対応のルータ７０の決定情報は、サービスマッピング部８６に渡されて、サービスマッピングテーブル８５と帯域予約許可判断部９１から得た帯域予約の情報とからＲＳＶＰ非対応のルータ７０に設定すべき値が決定される。サービスマッピングテーブル８５が図８に示したサービスマッピングテーブルだとすると、装置設定部８７は、ＣＯＰＳ受信部９０で受信したＲＳＶＰ対応のルータ５０における帯域予約情報が、ユーザ名「Ｋｕｒｏｓｅ」、帯域予約「５Ｍｂｐｓ」ということから、ユーザ名「Ｋｕｒｏｓｅ」に優先度「３」を割り当てる設定をする。この設定情報ｈは、ＳＮＭＰ送信部８８にてＲＳＶＰ非対応のルータ７０へ送信される。
ＲＳＶＰ非対応のルータ７０は、ＳＮＭＰ受信部７５にて設定情報ｈを受け取り、帯域予約項目設定部７６にて帯域予約項目の設定を行う。このとき、サービスマッピング部７７が優先度割り当て「３」に対応する帯域予約項目を決定し、その決定に従って、帯域予約実行部７８が帯域予約を行う。
ＲＳＶＰ対応のルータ５０は、アドミッション結果情報ｇをＣＯＰＳ受信部５７により受け取る。ここでは、アドミッション結果情報ｇは許可であるので、そのデータは帯域予約判断部５８に通知され、また、帯域予約判断部５８は、ＲＳＶＰプロトコルのＲｅｓｖメッセージｉをＲｅｓｖメッセージ送信部５６によりＲＳＶＰ非対応のルータ７０に送信する。帯域予約判断部５８は、通知されたアドミッション結果情報ｇが不許可であれば、その不許可情報ｎをクライアント４１に送信する。そして、許可の場合、帯域予約項目設定部６０は、サービスマッピング６１により帯域予約パラメータに対応した項目の値の設定を行い、帯域予約実行部６２が、帯域予約実行として帯域「５Ｍｂｐｓ」をユーザ名「Ｋｕｒｏｓｅ」の通信に割り当てる。
ＲＳＶＰ非対応のルータ７０は、Ｒｅｓｖメッセージ受信部７３によりＲＳＶＰプロトコルのＲｅｓｖメッセージｉを受信するが、処理できないので、Ｒｅｓｖメッセージ送信部７４によりそのままサーバ４２にＲＳＶＰプロトコルのＲｅｓｖメッセージｊとして送信する。
以上のようにして、第６の実施の形態では、ＲＳＶＰ対応のルータ５０が帯域予約のサービス要求を受け付けた場合に、その要求を許可するかどうかの判断はポリシサーバ８０が帯域予約判断ポリシテーブル８９および動的ネットワーク情報テーブル８２を基に動的に行い、アドミッション制御の際に受け取った情報と動的ネットワーク情報テーブル８２の内容が反映された経路情報テーブル８３とを基にサービス要求に対応していない経路上のルータ７０を動的に決定してそのルータにサービスを割り当てることができ、ＲＳＶＰ対応のルータおよびＲＳＶＰ非対応のルータが混在し、かつ動的に変化するネットワーク環境においても、ＲＳＶＰ非対応のネットワーク資源を有効に活用することができる。
また、上記のポリシサーバ８０を構成するコンピュータが有すべき機能の処理内容は、コンピュータで読み取り可能な記録媒体に記録されたプログラムに記述させておくことができる。このプログラムをコンピュータで実行することにより、上記の各処理がコンピュータで実現できる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置や半導体メモリなどがある。市場に流通させる場合には、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）やフロッピーディスクなどの可搬型記録媒体にプログラムを格納して流通させたり、ネットワークを介して接続されたコンピュータの記憶装置に格納しておき、ネットワークを通じて他のコンピュータに転送することもできる。コンピュータで実行する際には、コンピュータ内のハードディスク装置などにプログラムを格納しておき、メインメモリにロードして実行する。
上記については単に本発明の原理を示すものである。さらに、多数の変形、変更が当業者にとって可能であり、本発明は上記に示し、説明した正確な構成および応用例に限定されるものではなく、対応するすべての変形例および均等物は、添付の請求項およびその均等物による本発明の範囲とみなされる。
Claims (10)
- ネットワークサービス要求を受け付けて要求されたネットワークサービスを提供することができるサービス要求対応装置からネットワークサービス提供状態情報を知って、外部装置からネットワークサービス設定が可能であって設定されたネットワークサービスを提供することができるサービス要求非対応装置に対してネットワークサービス設定を行うサービス割り当て装置において、
前記サービス要求対応装置のネットワークサービス提供状態情報を収集するネットワーク情報収集手段と、
前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報を基に前記サービス要求対応装置が提供しているネットワークサービスを提供することができないサービス要求非対応装置を決定する設定装置決定手段と、
前記ネットワーク情報収集手段が収集したネットワークサービス提供状態情報と前記設定装置決定手段が決定したサービス要求非対応装置の情報とを基に前記サービス要求非対応装置に設定すべきサービスの決定を行うサービスマッピング手段と、
前記サービス要求非対応装置に前記サービスマッピング手段で決定されたサービスを設定するサービス設定手段と、
を備えていることを特徴とするサービス割り当て装置。 - 前記設定装置決定手段は、ネットワーク情報があらかじめ与えられた経路情報テーブルと、前記ネットワーク情報収集手段がネットワークサービス提供状態情報を収集した前記サービス要求対応装置のネットワーク情報を基に前記経路情報テーブルを参照して前記サービス要求非対応装置を決定する設定装置決定機能とを有することを特徴とする請求項１記載のサービス割り当て装置。
- 前記設定装置決定手段は、前記ネットワーク情報収集手段が前記サービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納するとともに前記ネットワーク情報を前記経路情報テーブルに反映させる動的ネットワーク情報テーブルを有することを特徴とする請求項２記載のサービス割り当て装置。
- 前記サービス要求対応装置から前記サービス要求対応装置が受け付けたネットワークサービス要求に対してネットワークサービスを提供するかどうかの許可判断の問い合わせを受けて、ネットワークサービス提供の許可判断を下し、判断結果を前記サービス要求対応装置に通知するとともに許可情報を前記サービス要求対応装置のネットワークサービス提供状態情報として前記設定装置決定機能および前記サービスマッピング手段に通知するネットワークサービス提供許可判断手段を備えていることを特徴とする請求項２記載のサービス割り当て装置。
- 前記ネットワークサービス提供許可判断手段は、ネットワークサービス要求に対する許可のルールをあらかじめ規定したポリシテーブルと、前記サービス要求対応装置からの問い合わせに対し前記ポリシテーブルを参照してネットワークサービス提供を許可するかどうかを判断する許可判断機能とを有していることを特徴とする請求項４記載のサービス割り当て装置。
- 前記設定装置決定手段は、前記ネットワーク情報収集手段が前記サービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納するとともに前記ネットワーク情報を前記経路情報テーブルに反映させる動的ネットワーク情報テーブルを有することを特徴とする請求項４記載のサービス割り当て装置。
- 前記設定装置決定手段は、前記ネットワーク情報収集手段が前記サービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納するとともに前記ネットワーク情報をネットワークサービス提供の許可判断用のデータとして前記許可判断機能に通知する動的ネットワーク情報テーブルを有することを特徴とする請求項５記載のサービス割り当て装置。
- 前記設定装置決定手段は、前記ネットワーク情報収集手段が前記サービス要求対応装置およびサービス要求非対応装置から定期的に収集したネットワーク情報を格納し、前記ネットワーク情報を前記経路情報テーブルに反映させるとともに前記ネットワーク情報をネットワークサービス提供の許可判断用のデータとして前記許可判断機能に通知する動的ネットワーク情報テーブルを有することを特徴とする請求項５記載のサービス割り当て装置。
- サービス要求対応装置が提供可能なネットワークサービスを提供することができない、前記サービス要求対応装置と同じ通信経路上にあるサービス非対応装置に、前記サービス要求対応装置が受け付けたネットワークサービス要求に相応のサービスの割り当てを行うサービス割り当て方法において、
前記サービス要求対応装置のネットワークサービス提供状態情報を取得してネットワークサービス提供状態を把握し、
前記ネットワークサービス提供状態情報を得た前記サービス要求対応装置のネットワーク情報とあらかじめ与えられた経路情報とからサービスの割り当てを行うべきサービス要求非対応装置を発見し、
前記ネットワークサービス提供状態情報と前記設定装置決定手段が決定したサービス要求非対応装置の情報とから前記サービス要求非対応装置に設定可能なサービスにパラメータ変換を行い、
パラメータ変換されたサービスを前記サービス要求非対応装置に設定する、
ことからなることを特徴とするサービス割り当て方法。 - サービス割り当てプログラムを記録したコンピュータ読み取り可能な記録媒体において、サービス要求対応装置のネットワークサービス提供状態情報を収集するとともに前記サービス要求対応装置およびサービス要求非対応装置から定期的にネットワーク情報を収集するネットワーク情報収集手段と、前記ネットワークサービス提供状態情報および／またはネットワーク情報を基に前記サービス要求対応装置が提供しているネットワークサービスを提供することができないサービス要求非対応装置を決定する設定装置決定手段と、前記ネットワークサービス提供状態情報と前記設定装置決定手段が決定したサービス要求非対応装置の情報とを基に前記サービス要求非対応装置に設定すべきサービスの決定を行うサービスマッピング手段と、前記サービス要求非対応装置に前記サービスマッピング手段で決定されたサービスを設定するサービス設定手段と、前記サービス要求対応装置から前記サービス要求対応装置が受け付けたネットワークサービス要求に対してネットワークサービスを提供するかどうかの許可判断の問い合わせを受けて、ネットワークサービス提供の許可判断を下し、判断結果を前記サービス要求対応装置に通知するとともに許可情報を前記サービス要求対応装置のネットワークサービス提供状態情報として前記設定装置決定機能に通知するネットワークサービス提供許可判断手段とを有するプログラムを記録したコンピュータ読み取り可能な記録媒体。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/JP1998/003913 WO2000013379A1 (fr) | 1998-08-31 | 1998-08-31 | Appareil d'affectation de service |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP3725424B2 true JP3725424B2 (ja) | 2005-12-14 |
Family
ID=14208912
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000568226A Expired - Fee Related JP3725424B2 (ja) | 1998-08-31 | 1998-08-31 | サービス割り当て装置 |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US7076540B2 (ja) |
| JP (1) | JP3725424B2 (ja) |
| WO (1) | WO2000013379A1 (ja) |
Families Citing this family (40)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6742045B1 (en) * | 1999-07-02 | 2004-05-25 | Cisco Technology, Inc. | Handling packet fragments in a distributed network service environment |
| WO2001003380A1 (fr) * | 1999-07-02 | 2001-01-11 | Fujitsu Limited | Dispositif d'attribution de services |
| US6839766B1 (en) * | 2000-01-14 | 2005-01-04 | Cisco Technology, Inc. | Method and apparatus for communicating cops protocol policies to non-cops-enabled network devices |
| US6775701B1 (en) * | 2000-08-15 | 2004-08-10 | Nortel Networks Limited | Oversubscribing network resources |
| US20020143914A1 (en) * | 2001-03-29 | 2002-10-03 | Cihula Joseph F. | Network-aware policy deployment |
| US20050060365A1 (en) * | 2002-01-24 | 2005-03-17 | Robinson Scott L. | Context-based information processing |
| US7489687B2 (en) * | 2002-04-11 | 2009-02-10 | Avaya. Inc. | Emergency bandwidth allocation with an RSVP-like protocol |
| US7477657B1 (en) * | 2002-05-08 | 2009-01-13 | Juniper Networks, Inc. | Aggregating end-to-end QoS signaled packet flows through label switched paths |
| US10171593B2 (en) * | 2014-06-30 | 2019-01-01 | Verizon Patent And Licensing Inc. | Validating web services for compatibility with a client device by emulating the client device by populating a template associated with the web services |
| JP3985638B2 (ja) * | 2002-09-11 | 2007-10-03 | 日本電気株式会社 | Ｒｓｖｐ代理応答ルータ、ｒｓｖｐ代理応答システム及びそれに用いるｒｓｖｐ代理応答方法 |
| US20040073690A1 (en) * | 2002-09-30 | 2004-04-15 | Neil Hepworth | Voice over IP endpoint call admission |
| US8176154B2 (en) | 2002-09-30 | 2012-05-08 | Avaya Inc. | Instantaneous user initiation voice quality feedback |
| US7359979B2 (en) | 2002-09-30 | 2008-04-15 | Avaya Technology Corp. | Packet prioritization and associated bandwidth and buffer management techniques for audio over IP |
| KR100595585B1 (ko) | 2003-05-13 | 2006-07-03 | 엘지전자 주식회사 | 이동통신시스템에서의 멀티미디어 방송 및 멀티캐스트서비스를 위한 무선자원관리방법 |
| US8098669B2 (en) * | 2003-08-04 | 2012-01-17 | Intel Corporation | Method and apparatus for signaling virtual channel support in communication networks |
| US20050058130A1 (en) * | 2003-08-04 | 2005-03-17 | Christ Chris B. | Method and apparatus for assigning data traffic classes to virtual channels in communications networks |
| JP2005149336A (ja) * | 2003-11-19 | 2005-06-09 | Hitachi Ltd | ストレージ管理方法及びその装置 |
| US7698366B2 (en) * | 2004-02-12 | 2010-04-13 | Avaya, Inc. | Method and apparatus for facilitating the transportation of medical images on a communication network |
| US20050213557A1 (en) * | 2004-03-26 | 2005-09-29 | Cherng-Daw Hwang | Multimedia communication and collaboration system and protocols |
| WO2005103897A1 (en) * | 2004-04-23 | 2005-11-03 | Matsushita Electric Industrial Co., Ltd. | Network resource management device |
| US7978827B1 (en) * | 2004-06-30 | 2011-07-12 | Avaya Inc. | Automatic configuration of call handling based on end-user needs and characteristics |
| US7984149B1 (en) * | 2004-08-04 | 2011-07-19 | Cisco Technology, Inc. | Method and apparatus for identifying a policy server |
| US7801039B2 (en) * | 2005-02-14 | 2010-09-21 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and nodes for performing bridging of data traffic over an access domain |
| US7769859B1 (en) * | 2005-04-15 | 2010-08-03 | Cisco Technology, Inc. | Controlling access to managed objects in networked devices |
| TWI295887B (en) * | 2005-04-20 | 2008-04-11 | Compal Electronics Inc | Method for sending and receiving data |
| US7636302B2 (en) | 2005-05-20 | 2009-12-22 | Cisco Technology, Inc. | Avoiding unnecessary RSVP-based preemptions |
| US7810041B2 (en) * | 2006-04-04 | 2010-10-05 | Cisco Technology, Inc. | Command interface |
| JP4979281B2 (ja) * | 2006-06-19 | 2012-07-18 | キヤノン株式会社 | 画像処理装置及びその制御方法と画像処理システム |
| US7617337B1 (en) | 2007-02-06 | 2009-11-10 | Avaya Inc. | VoIP quality tradeoff system |
| US7693060B2 (en) * | 2007-10-12 | 2010-04-06 | Cisco Technology, Inc. | Method and apparatus for a reservation reflector function in routers |
| US8391492B1 (en) * | 2008-06-25 | 2013-03-05 | Cisco Technology, Inc. | Secure resource reservation protocol (RSVP) with dynamic group keying |
| US8218751B2 (en) | 2008-09-29 | 2012-07-10 | Avaya Inc. | Method and apparatus for identifying and eliminating the source of background noise in multi-party teleconferences |
| US8478812B2 (en) * | 2009-09-29 | 2013-07-02 | Core Wireless S.A.R.L. | Method and apparatus for providing device compatibility information |
| US9112930B2 (en) * | 2012-10-26 | 2015-08-18 | Microsoft Technology Licensing, Llc | Updating services during real-time communication and sharing-experience sessions |
| US9407560B2 (en) | 2013-03-15 | 2016-08-02 | International Business Machines Corporation | Software defined network-based load balancing for physical and virtual networks |
| US9769074B2 (en) | 2013-03-15 | 2017-09-19 | International Business Machines Corporation | Network per-flow rate limiting |
| US9596192B2 (en) | 2013-03-15 | 2017-03-14 | International Business Machines Corporation | Reliable link layer for control links between network controllers and switches |
| US9444748B2 (en) * | 2013-03-15 | 2016-09-13 | International Business Machines Corporation | Scalable flow and congestion control with OpenFlow |
| US9609086B2 (en) | 2013-03-15 | 2017-03-28 | International Business Machines Corporation | Virtual machine mobility using OpenFlow |
| US10453114B2 (en) | 2013-06-23 | 2019-10-22 | Intel Corporation | Selective sharing of user information based on contextual relationship information, such as to crowd-source gifts of interest to a recipient |
Family Cites Families (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5581558A (en) * | 1995-03-29 | 1996-12-03 | Lucent Technologies Inc. | Apparatus for bridging non-compatible network architectures |
| CA2186795A1 (en) | 1995-11-17 | 1997-05-18 | Cormac John Sreenan | Resource management system for a broadband multipoint bridge |
| US6021263A (en) * | 1996-02-16 | 2000-02-01 | Lucent Technologies, Inc. | Management of ATM virtual circuits with resources reservation protocol |
| JP3372797B2 (ja) | 1996-12-06 | 2003-02-04 | 日本電気株式会社 | 帯域予約制御方式 |
| US5889954A (en) * | 1996-12-20 | 1999-03-30 | Ericsson Inc. | Network manager providing advanced interconnection capability |
| US6356863B1 (en) * | 1998-09-08 | 2002-03-12 | Metaphorics Llc | Virtual network file server |
| US6563793B1 (en) * | 1998-11-25 | 2003-05-13 | Enron Warpspeed Services, Inc. | Method and apparatus for providing guaranteed quality/class of service within and across networks using existing reservation protocols and frame formats |
| US6539425B1 (en) * | 1999-07-07 | 2003-03-25 | Avaya Technology Corp. | Policy-enabled communications networks |
-
1998
- 1998-08-31 JP JP2000568226A patent/JP3725424B2/ja not_active Expired - Fee Related
- 1998-08-31 WO PCT/JP1998/003913 patent/WO2000013379A1/ja active Application Filing
-
2001
- 2001-02-20 US US09/788,842 patent/US7076540B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| WO2000013379A1 (fr) | 2000-03-09 |
| US20010056459A1 (en) | 2001-12-27 |
| US7076540B2 (en) | 2006-07-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3725424B2 (ja) | サービス割り当て装置 | |
| JP3816390B2 (ja) | サービス割り当て装置 | |
| JP3977331B2 (ja) | Ｉｐ通信網における方法及び装置 | |
| US6092113A (en) | Method for constructing a VPN having an assured bandwidth | |
| JP3613863B2 (ja) | ネットワーク接続システム及び並列ネットワーク接続方法 | |
| JP4213972B2 (ja) | ネットワークのパス構成のための方法および装置 | |
| US7035279B2 (en) | Flow allocation in a ring topology | |
| EP1021015B1 (en) | System for policy-based network configuration | |
| US7327681B2 (en) | Admission control method in internet differentiated service network | |
| US6507873B1 (en) | Network address assigning system | |
| US20040162901A1 (en) | Method and apparatus for policy based class service and adaptive service level management within the context of an internet and intranet | |
| US20050198224A1 (en) | Storage network system and control method thereof | |
| KR20050085155A (ko) | 레이어드 네트워크 아키텍처의 계층적 자원관리 장치 및방법 | |
| JP2003513511A (ja) | 通信ネットワークのためのｒｓｖｐプロキシサービス | |
| US6205484B1 (en) | Controlling access to resources in a connectionless network using a ticket message containing reserved network resource allocation information | |
| US20050223150A1 (en) | Resource management device, resource management system, and resource management method | |
| JP2008541555A (ja) | データネットワークにおけるリソースの予約のための方法および構成 | |
| JP2000312226A (ja) | 通信品質を保証する方法 | |
| JP2002374286A (ja) | 通信品質制御システムおよび通信品質制御方法 | |
| CN100544357C (zh) | 一种端到端服务质量的域间协商的方法及其系统 | |
| Khalil et al. | Implementation of a bandwidth broker for dynamic end-to-end capacity reservation over multiple diffserv domains | |
| JP2001036581A (ja) | 通信帯域設定システムと方法 | |
| KR100739489B1 (ko) | 서버와 클라이언트의 사이의 네트워크 경로에 속하는라우터에 접속하는 대역폭 브로커 및 차등화 서비스 제공방법 | |
| JP2008294983A (ja) | 優先制御システム、優先設定制御システム、優先制御装置、及び優先制御方法 | |
| JP3628557B2 (ja) | 通信品質制御装置および記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040303 |
|
| 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: 20050920 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050921 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080930 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090930 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090930 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100930 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100930 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110930 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120930 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120930 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130930 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |